Hey David,

  I agree it’s a good idea to test the system.  I think it depends on who you use for your service.  I’ve seen good/bad services out there.  So shop around.  Cheap isn’t always the best way to go.  Most offer a 24-73 hr free trial.  I’d use that time to make sure they’re a reliable service.  I can tell  you I’ve had great luck using this provider for a Windows server & Linux servers:

 

https://www.nfoservers.com

 

I know quite a few others who use them as well.  I get nothing for passing the info on.  Just a happy customer of their service.  73 de K4SQI!

 

Steve, K4SQI

 

From: David McGough
Sent: Monday, May 21, 2018 5:41 PM
To: Users of Asterisk app_rpt
Subject: Re: [App_rpt-users] AllStar nodes in the Cloud

 

 

Hi Everyone,

 

I've got some thoughts to consider about VPS based AllStar installations.

 

AllStar uses the Asterisk dahdi drivers for critical timing and the

conference/bridging capability we all depend on.

 

Most VPS installations will have very poor dahdi timer quality, due to

the inherent "jitter" the VPS instances incur from sharing CPU time slices

with many other guests. This jitter has minimal impact on most

applications you might host on a VPS---like a web server, file server,

etc.  However, the jitter can have serious side effects for VoIP

applications, like AllStar.

 

The way you test the dahdi timing performance is with the dahdi_test

program. On older ACID installations, this program was called zttest.

 

As dahdi_test numbers fall below about 99.97%, poor timing quality has

more and more of an impact. There are several symptoms of this problem to

watch out for. Whether or not ANY of these symptoms will impact a given

VPS user depends on how you use your AllStar installation.

 

AllStar timing-related problems fall into two basic categories:

 

1) Call quality issues--pops, clicks and stuttering audio. Most frequently

this is heard when using Asterisk to transcode between multiple audio

CODECs or when playing audio files (like the localplay of playback

commands). Recording/archiving audio from the node could be impacted, too.

 

2) General timing woes. For example: a timeout timer is slower or faster

than the speed you've set. Or, the node is configured to ID every 10

minutes. In reality, it IDs every 9 or 10.5 minutes. This list of

potential problems includes all the various timer settings found in the

rpt.conf file, etc. Fortunately, a lot of these timing concerns aren't

typically applicable to VPS-based pseudo nodes---for example: of what use

is a CW ID on a pseudo node anyway?

 

For more info about dahdi timing concerns, just google search phrases

like: "dahdi_test results"  or "bad dahdi_test".

 

Anyhow, with all the interest in VPS based installs of AllStar, it's worth

remembering about timer quality concerns---strange audio quality problems

are likely not AllStar's fault!

 

 

73, David KB4FXC

 

 

_______________________________________________

App_rpt-users mailing list

App_rpt-users@lists.allstarlink.org

http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users

 

To unsubscribe from this list please visit http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button"

You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.