Hello everyone, Long time reader of the list, but first time poster. :-) Steve, K4SQI here. I've noticed there's been a lot more interest in this subject lately. So I figured I'd post my results. I've been running multiple AllStar Hubs/Nodes in the cloud for several months now. Using various configurations. 1 core 512 Meg memory, 1 gig memory, etc. They all work flawlessly. I've installed them on both Debian & Ubuntu. Used the repo's Steve, N4IRS has setup & compiled multiple instances directly from the github repo so I could test different things. My Primary AllStar Node 46626 is setup on one cloud server & is tied full time to my Digital Link system called the Carolina Link. 99% of that system is all cloud based thanks to the hard work of Steve, N4IRS & Mike, N4IRR and the BM Network. So my thanks goes out to them. I still have multiple nodes setup here on PI's/Odroid's for personal use, but personally for bigger hubs/nodes, I think the cloud is the way to go. Just my 0.02. :-) 73 de K4SQI! Steve, K4SQI -- ----- Steve, kb7sqi@gmail.com
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
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.
participants (3)
-
David McGough -
Steven Blackford -
Steven D. Blackford