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:
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!
···
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:
- 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.
- 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.
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.