Sorry if there was confusion. I'm not recommending you set up Terraform, I'm recomending you use what my friend set up using Terraform. It would build everything you need to have a functional server.
The yum package manager should be able to install everything you need. But as Vincenzo said you could also use an Ubuntu AMI instead and follow the existing instructions.
Terraform is basically a tool that let's you describe installations for the cloud that can be recreated automatically, and my friend made one that creates a Jamulus install.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
By following Vincento's and Gilgongo's suggestions I think my ubuntu 18. 04 LTS (HVM), SSD Volume Type is now running (thanks to all of you guys!) and I can start Jamulus as a headless server although the only clue is a number that appears after running the shell script from Vincenzo. If I run the script again the same number appears but is followed by a number in parenthesis that increments by one at each execution of the script. But I am not sure if things are as they should be. i am guessing this means more than one instance of the Jamulus server is starting each time. When I run the client on my home windows 10 pc and attempt to connect by inserting the public ip from AWS it says ' trying to connect ' but cannot. The incoming and outgoing rules are still at the default settings - 0.0.0.0/0 ... How should they be edited? (if that could be the problem?) Thanks for your patience!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do not launch it more than one time. The only "difficult" task is to stop it, but normally you do not need to do it.
Anyway:
the security group should be configured as in the screenshot. If you already have all running, you may modify its security group by selecting the instance, look in the bottom, there is a way to reach the security group and edit the rules (or go to Security Groups in the left bar).
if you did not implement the jamulus.service thing, you may check what is happening with this command:tail -f nohoup.out (because in such file there is a log)
if you have to stop the process, list your processes with ps or top, note the PID on left for Jamulus, then kill PID .
Maybe, if you are more familiar with Windows, you might follow Andrew suggestion: just use Windows on AWS.
FYI I've been uploading Jamulus AMIs to all of the US AWS regions. To launch your own private server, just search the Community AMIs for "jamulus" and choose it, then choose your instance type (I've been using t3.small). Next you need to make sure you open up UDP to the world so go to security groups and add a rule with type "All UDP" with source "Anywhere". Launch the instance and Jamulus will start up automatically :)
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Simon Tomlinson has this very nice "Idiot Guide to setup a Jamulus Server on AWS ..." on the Jamulus Musician's Facebook page ... I think it is extremely helpful
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been running an instance of Ubuntu on Lightsail for a few months now. I set it up as per the instructions posted on Facebook by Simon Tomlinson. It definitely works. Delay is annoyingly between 55 and 80, but whatever. The problem I'm having (which is rendering Jamulus near unusable, as I'm trying to teach music lessons) is the bubbling underwater audio quality that often degrades to unintelligible garbling. Is anyone else getting this? I've got audio quality set to "High" in the Jamulus settings, and have quality, trustworthy audio gear, and fast-enough ethernet connection. I'm beginning to suspect this is an artifact caused by the server itself. Any ideas would be much appreciated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Does the bubbling happen when you are on the server alone or when others
are joining you? I confess I don’t know much about how the software works
but I had so much crackling and dropouts at first that I could not jam with
anyone ... then I upgraded my internet to the fastest level with Shaw, and
bought a 100Ft Cat7 shielded cable from my router to computer then all that
trouble vanished (the latency issue still remains, of course). I don’t know
if a student with low quality connection would be the cause?? I would be
interested to see a response from the tech gurus.
I've been running an instance of Ubuntu on Lightsail for a few months now.
I set it up as per the instructions posted on Facebook by Simon Tomlinson.
It definitely works. Delay is annoyingly between 55 and 80, but whatever.
The problem I'm having (which is rendering Jamulus near unusable, as I'm
trying to teach music lessons) is the bubbling underwater audio quality
that often degrades to unintelligible garbling. Is anyone else getting
this? I've got audio quality set to "High" in the Jamulus settings, and
have quality, trustworthy audio gear, and fast-enough ethernet connection.
I'm beginning to suspect this is an artifact caused by the server itself.
Any ideas would be much appreciated.
Great question, thanks! Unfortunately, the bubbling happens even when I'm alone. I read somewhere that bubbling sounds originate from network problems, and crackling from internal audio processing problems.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Have you made sure you're not running any other disk-intensive tasks on the PC that is running the Jamulus client - e.g. backup software or cloud sync software?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Kevin,
Two things to try:
1) Upgrade to the newest version. Versions of Jamulus starting with 3.6.0 have some changes in the communications protocol that eliminate some of the errors when packets are delivered by the Internet out of order. That is often the cause of that "bubbly" sound.
2) Try going to lower quality and bugger buffers. Lower quality requires less Internet capability. Bigger buffers can sort out some of the communications errors. I realise that with that big a delay you will no want to stay with big buffers, but try to see if that helps the sound quality any.
This sounds like Internet connection problems and there is not a lot that the program can do about that. Note that the speed of the Internet connection is not the big problem. The main problem is the jitter, the regularity of the connection. And do be sure to use a cabled connection and not wifi. That makes a big difference.
Maybe try finding another cloud provider. 80ms is an awful lot. I find that 50ms is about the maximum that is usable.
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Lightsail is on a shared instance; it is not obvious that bandwidth and processor are always 100% available. The baseline usage for the cheapest server is 5% of CPU usage (https://lightsail.aws.amazon.com/ls/docs/en_us/articles/amazon-lightsail-viewing-instance-burst-capacity ). This means on average you have to use 5%, which means you may go welll beyond, if most of the time you stay well below. Regarding the network , there is no info on how it is shared.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been recently setting up a Jamulus server for an accordion ensemble across six sites. Here is the beef: for tolerable latency, you don't want the server at anybody's home Internet connection but close to some backbone/switchover. Even for a two-person setup, a private server means that the non-server party's data has to squeeze out and in and out and in through two private Internet connections (and the corresponding legs) rather than one. That implies a rented server. For reasonably good quality, you want an overpowered server that manages receiving, decompression, mixing, recompression, sending for all of your sources without spending all of its time slot on it. "Overpowered" and "affordable" suggests a server that you pay for only while it is being overpowered. Those tend to be virtualised, meaning you don't get to have realtime behavior, meaning you want them even more overpowered.
Of course, you want a data center with good ping times at least to your own computer or this is useless anyway.
In tests with the full ensemble I ended up picking a server that's a lot more powerful than I'd have expected: basically 12 virtual cores across 3 virtual CPUs. That leaves reasonable reserves (I suppose) for system tasks (Ubuntu 20.04 here) while supporting "high quality", "mono-in/stereo-out" and recording with comparatively low latency. This overkill means that we'll spend 50¢ on two hours of practice, and I have to create a server from scratch, give it a DynDNS name, and remove it again after each rehearsal. I've got the procedure down to few minutes, and having a docker file is part of it (thanks for that!).
So if you find some cloud server provider with the kind of dynamic plan allowing you to go full hog for limited stretches of time, it may well be worth testing out options that on paper look like overkill. There is a chance that you'll find the overkill worth the cost as long as you figure out a way to confine its use to active practice times.
Of course, for an open jamming server, that's less of a great proposition than for something which you need weekly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I too decided to go with a larger server, open only for rehearsals (c5.large), mostly because I have read somewhere that also the network is shared in shared instances. However, I just switch on and off, without terminating it (12-15GB EBS does not cost much - about 0.05/day). I use 18.04 because the default install takes less disk space. I just give the IP address every time to my friends, no need for a domain name.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I too decided to go with a larger server, open only for rehearsals
(c5.large), mostly because I have read somewhere that also the network
is shared in shared instances.
Ok, that may actually also be relevant. Probably depends on the
provider, but of course it stands to reason that if you only rent a
fraction of a server, the bandwidth or at least the latency with which
it gets delivered is likely less dependable.
However, I just switch on and off, without terminating it (12-15GB EBS
does not cost much - about 0.05/day). I use 18.04 because the default
install takes less disk space. I just give the IP address every time
to my friends, no need for a domain name.
Well, I just give the IP address every time to a script. That's less
tedious for most involved. The script is called dynv6.sh and looks like
the following:
!/bin/sh
if [ $# = 1 ]
then
ssh-keygen -f "/home/[myusername]/.ssh/known_hosts" -R "[myhostname].dynv6.net"
ssh -l root "$1" wget -q "'https://ipv4.dynv6.com/api/update?ipv4=auto&token=[mytoken]&zone=[myhostname].dynv6.net'" -O -
else
wget -q 'https://ipv4.dynv6.com/api/update?ipv4=auto&token=[mytoken]&zone=[myhostname].dynv6.net' -O -
fi
When called without argument, it sets the dynamic IP address to the
current computer. I actually transferred that script to my first
installations but later decided that I did not want to have my DynDNS
credentials lying around on cloud servers. It's not hard to guess what
dynamic DNS provider I used here, but others have similar mechanisms for
updating their records.
This allowed me for a test of several servers (which I then set up at
the same time) to tell people "ok, now everybody disconnect, and
reconnect in a minute". If you have a set of 7 people with different
level of technical knowledge, keying in something different and hoping
that everyone gets it right is just not as brainless as that.
--
David Kastrup
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
how long does it take to propagate a change in IP address for a DynDNS domain?
In my experience, it's pretty fast. Less than half a minute or so. It
probably depends on what kind of timeout the DNS records of the
respective DynDNS provider advertise. But I don't really know the exact
mechanisms.
--
David Kastrup
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks David, I tried a DynDNS domain and it was very fast; I expected much longer propagation times. Funnily enough, one of my friends what disoriented by the domain instead of the usual ever-changing IP, but he will get used :) .
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the great advice! I made a snapshot of my Ubuntu instance on Lightsail (as per Simon Tomlinson's great instructions on Facebook), and made a new instance of the same server but with an upgraded plan. Now the new instance, which being a snapshot, is an identical copy of the other functioning instance, isn't working. It's running, but I can't connect to it from Jamulus using the new public ip. Any ideas why?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the great advice! I made a snapshot of my Ubuntu instance
on Lightsail (as per Simon Tomlinson's great instructions on
Facebook), and made a new instance of the same server but with an
upgraded plan. Now the new instance, which being a snapshot, is an
identical copy of the other functioning instance, isn't working. It's
running, but I can't connect to it from Jamulus using the new public
ip. Any ideas why?
Any firewall rules or DNS entries or similar tied to the old IP address
in your identical copy?
--
David Kastrup
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Recently I've been using a t3.small instance with dedicated tenancy and it has been rock solid for jams with 8 or 10 folks. I noticed a significant difference between using the same instance type with default tenancy. Note that the dedicated tenancy is expensive - you get charged $2 every hour if you have one or more dedicated instances running. For this reason I start the server when we start playing and try to remember to stop it when we are done!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Since testing different platforms costs almost nothing, you may try some cheaper alternative - c5.large is about 0.10$/hour, and likely more than adequate.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree. As I download recordings, the major cost for me is data transfer out, rather than on-demand time. I minimise this by compressing the recording folders to .zip before transfer which reduces data transfer volume by about 60%.
I still find that EC2 is much cheaper than Lightsail, with better performance - as long as I turn the instances off between sessions. Lightsail is only better if you have high volumes of data transfer out - so if you're not recording sessions, EC2 is a no-brainer instead. And even if you are, you'd have to record a lot of session-hours for it to be more expensive.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I too record and download, and recently started to zip everything; however, I never thought at transfer costs, thanks for the heads up (though my monthly bill is negligible). I know a fixed cost is the EBS, but affordable in the sizes we need if we delete recordings. By the way, I recently developed a web interface to toggle recording and download zips (check here: https://sourceforge.net/p/llcon/discussion/software/thread/4288b44c95/ ).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've tried three different servers: A lightsail instance, another Lightsail instance with more processor power, and an EC2. All three are running and can connect to Jamulus. The bubbling and dropouts make the experience utterly useless, however. I'm beginning to think the problem is somewhere on my end. A question: If there were a firewall/port etc. issue, wouldn't it not work at all, or would that create a bottleneck that might be causing these artifacts? I'm beginning to suspect that the main modem which my router is connected to via ethernet (and which is owned by my landlord and is not being made accessible to me) might be the culprit. My router has (i believe) all the necessary port forwarding and firewall rules in place- because again, I can connect to Jamulus, and everything works fine... except for the gawdawful bubbling and audio dropouts. And by the way, I can turn the buffers all the way up with no change in the bubbling or dropouts. In fact, no change in packet size, audio quality, etc. makes any difference.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've tried three different servers: A lightsail instance, another
Lightsail instance with more processor power, and an EC2. All three
are running and can connect to Jamulus. The bubbling and dropouts make
the experience utterly useless, however. I'm beginning to think the
problem is somewhere on my end. A question: If there were a
firewall/port etc. issue, wouldn't it not work at all, or would that
create a bottleneck that might be causing these artifacts?
It would not work at all.
I'm beginning to suspect that the main modem which my router is
connected to via ethernet (and which is owned by my landlord and is
not being made accessible to me) might be the culprit.
That may well be the case. One of our orchestra members has a cable
modem and that was responsible for dropping and retransmitting an insane
number of packets (possibly because of being wired up without proper
line termination everywhere). A newer cable modem helped. Frequent
dropouts are consistent with retransmission: for a TCP stream that can
tolerate a certain amount of latency, this is mostly transparent. For
just-in-time stuff at high bandwidth, it becomes very noticeable. It is
a pity that you cannot access the router. Any chance to get your own
line?
My router has (i believe) all the necessary port forwarding and
firewall rules in place- because again, I can connect to Jamulus, and
everything works fine...
You need absolutely zero rules in place at the client side.
Prioritising traffic to Jamulus ports may help a bit when the upstream
is saturated, but it's not really making a significant difference in
overall behavior.
except for the gawdawful bubbling and audio dropouts. And by the way,
I can turn the buffers all the way up with no change in the bubbling
or dropouts. In fact, no change in packet size, audio quality,
etc. makes any difference.
I'm currently with Ionos in Germany, and the last rehearsal that went
reasonably well (but not without problems) was on a 12 vCPU plan
(distributed across 3 processors). On Friday I'll check out the largest
baremetal in my current plan which has just 4 cores. Because setup time
alone is announced at 20 minutes, I'll not test in advance. My hope is
that using baremetal will give me realtime priorities (which I
apparently don't have on the vCPUs) in which case the tradeoff of less
power versus proper priorisation of the power should be a net win. I
expect this to consistently either run comparatively smoothly or
comparatively horribly with 6 clients, with not a lot of potential for
in-between.
Not yet checked other providers: regarding the ping times, EC2 in
Frankfurt does not seem like the worst choice for me either.
--
David Kastrup
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry if there was confusion. I'm not recommending you set up Terraform, I'm recomending you use what my friend set up using Terraform. It would build everything you need to have a functional server.
The yum package manager should be able to install everything you need. But as Vincenzo said you could also use an Ubuntu AMI instead and follow the existing instructions.
Terraform is basically a tool that let's you describe installations for the cloud that can be recreated automatically, and my friend made one that creates a Jamulus install.
By following Vincento's and Gilgongo's suggestions I think my ubuntu 18. 04 LTS (HVM), SSD Volume Type is now running (thanks to all of you guys!) and I can start Jamulus as a headless server although the only clue is a number that appears after running the shell script from Vincenzo. If I run the script again the same number appears but is followed by a number in parenthesis that increments by one at each execution of the script. But I am not sure if things are as they should be. i am guessing this means more than one instance of the Jamulus server is starting each time. When I run the client on my home windows 10 pc and attempt to connect by inserting the public ip from AWS it says ' trying to connect ' but cannot. The incoming and outgoing rules are still at the default settings - 0.0.0.0/0 ... How should they be edited? (if that could be the problem?) Thanks for your patience!
Do not launch it more than one time. The only "difficult" task is to stop it, but normally you do not need to do it.
Anyway:
tail -f nohoup.out(because in such file there is a log)psortop, note the PID on left for Jamulus, thenkill PID.Maybe, if you are more familiar with Windows, you might follow Andrew suggestion: just use Windows on AWS.
Last edit: Vincenzo 2020-05-18
FYI I've been uploading Jamulus AMIs to all of the US AWS regions. To launch your own private server, just search the Community AMIs for "jamulus" and choose it, then choose your instance type (I've been using t3.small). Next you need to make sure you open up UDP to the world so go to security groups and add a rule with type "All UDP" with source "Anywhere". Launch the instance and Jamulus will start up automatically :)
Simon Tomlinson has this very nice "Idiot Guide to setup a Jamulus Server on AWS ..." on the Jamulus Musician's Facebook page ... I think it is extremely helpful
I've been running an instance of Ubuntu on Lightsail for a few months now. I set it up as per the instructions posted on Facebook by Simon Tomlinson. It definitely works. Delay is annoyingly between 55 and 80, but whatever. The problem I'm having (which is rendering Jamulus near unusable, as I'm trying to teach music lessons) is the bubbling underwater audio quality that often degrades to unintelligible garbling. Is anyone else getting this? I've got audio quality set to "High" in the Jamulus settings, and have quality, trustworthy audio gear, and fast-enough ethernet connection. I'm beginning to suspect this is an artifact caused by the server itself. Any ideas would be much appreciated.
Does the bubbling happen when you are on the server alone or when others
are joining you? I confess I don’t know much about how the software works
but I had so much crackling and dropouts at first that I could not jam with
anyone ... then I upgraded my internet to the fastest level with Shaw, and
bought a 100Ft Cat7 shielded cable from my router to computer then all that
trouble vanished (the latency issue still remains, of course). I don’t know
if a student with low quality connection would be the cause?? I would be
interested to see a response from the tech gurus.
On Fri, Dec 18, 2020 at 12:27 PM Kevin Nortness knortness@users.sourceforge.net wrote:
Great question, thanks! Unfortunately, the bubbling happens even when I'm alone. I read somewhere that bubbling sounds originate from network problems, and crackling from internal audio processing problems.
Have you made sure you're not running any other disk-intensive tasks on the PC that is running the Jamulus client - e.g. backup software or cloud sync software?
Hi Kevin,
Two things to try:
1) Upgrade to the newest version. Versions of Jamulus starting with 3.6.0 have some changes in the communications protocol that eliminate some of the errors when packets are delivered by the Internet out of order. That is often the cause of that "bubbly" sound.
2) Try going to lower quality and bugger buffers. Lower quality requires less Internet capability. Bigger buffers can sort out some of the communications errors. I realise that with that big a delay you will no want to stay with big buffers, but try to see if that helps the sound quality any.
This sounds like Internet connection problems and there is not a lot that the program can do about that. Note that the speed of the Internet connection is not the big problem. The main problem is the jitter, the regularity of the connection. And do be sure to use a cabled connection and not wifi. That makes a big difference.
Maybe try finding another cloud provider. 80ms is an awful lot. I find that 50ms is about the maximum that is usable.
Don
Lightsail is on a shared instance; it is not obvious that bandwidth and processor are always 100% available. The baseline usage for the cheapest server is 5% of CPU usage (https://lightsail.aws.amazon.com/ls/docs/en_us/articles/amazon-lightsail-viewing-instance-burst-capacity ). This means on average you have to use 5%, which means you may go welll beyond, if most of the time you stay well below. Regarding the network , there is no info on how it is shared.
I've been recently setting up a Jamulus server for an accordion ensemble across six sites. Here is the beef: for tolerable latency, you don't want the server at anybody's home Internet connection but close to some backbone/switchover. Even for a two-person setup, a private server means that the non-server party's data has to squeeze out and in and out and in through two private Internet connections (and the corresponding legs) rather than one. That implies a rented server. For reasonably good quality, you want an overpowered server that manages receiving, decompression, mixing, recompression, sending for all of your sources without spending all of its time slot on it. "Overpowered" and "affordable" suggests a server that you pay for only while it is being overpowered. Those tend to be virtualised, meaning you don't get to have realtime behavior, meaning you want them even more overpowered.
Of course, you want a data center with good ping times at least to your own computer or this is useless anyway.
In tests with the full ensemble I ended up picking a server that's a lot more powerful than I'd have expected: basically 12 virtual cores across 3 virtual CPUs. That leaves reasonable reserves (I suppose) for system tasks (Ubuntu 20.04 here) while supporting "high quality", "mono-in/stereo-out" and recording with comparatively low latency. This overkill means that we'll spend 50¢ on two hours of practice, and I have to create a server from scratch, give it a DynDNS name, and remove it again after each rehearsal. I've got the procedure down to few minutes, and having a docker file is part of it (thanks for that!).
So if you find some cloud server provider with the kind of dynamic plan allowing you to go full hog for limited stretches of time, it may well be worth testing out options that on paper look like overkill. There is a chance that you'll find the overkill worth the cost as long as you figure out a way to confine its use to active practice times.
Of course, for an open jamming server, that's less of a great proposition than for something which you need weekly.
I too decided to go with a larger server, open only for rehearsals (c5.large), mostly because I have read somewhere that also the network is shared in shared instances. However, I just switch on and off, without terminating it (12-15GB EBS does not cost much - about 0.05/day). I use 18.04 because the default install takes less disk space. I just give the IP address every time to my friends, no need for a domain name.
"Vincenzo" vdm@users.sourceforge.net writes:
Ok, that may actually also be relevant. Probably depends on the
provider, but of course it stands to reason that if you only rent a
fraction of a server, the bandwidth or at least the latency with which
it gets delivered is likely less dependable.
Well, I just give the IP address every time to a script. That's less
tedious for most involved. The script is called dynv6.sh and looks like
the following:
!/bin/sh
if [ $# = 1 ]
then
ssh-keygen -f "/home/[myusername]/.ssh/known_hosts" -R "[myhostname].dynv6.net"
ssh -l root "$1" wget -q "'https://ipv4.dynv6.com/api/update?ipv4=auto&token=[mytoken]&zone=[myhostname].dynv6.net'" -O -
else
wget -q 'https://ipv4.dynv6.com/api/update?ipv4=auto&token=[mytoken]&zone=[myhostname].dynv6.net' -O -
fi
When called without argument, it sets the dynamic IP address to the
current computer. I actually transferred that script to my first
installations but later decided that I did not want to have my DynDNS
credentials lying around on cloud servers. It's not hard to guess what
dynamic DNS provider I used here, but others have similar mechanisms for
updating their records.
This allowed me for a test of several servers (which I then set up at
the same time) to tell people "ok, now everybody disconnect, and
reconnect in a minute". If you have a set of 7 people with different
level of technical knowledge, keying in something different and hoping
that everyone gets it right is just not as brainless as that.
--
David Kastrup
how long does it take to propagate a change in IP address for a DynDNS domain?
"Vincenzo" vdm@users.sourceforge.net writes:
In my experience, it's pretty fast. Less than half a minute or so. It
probably depends on what kind of timeout the DNS records of the
respective DynDNS provider advertise. But I don't really know the exact
mechanisms.
--
David Kastrup
Thanks David, I tried a DynDNS domain and it was very fast; I expected much longer propagation times. Funnily enough, one of my friends what disoriented by the domain instead of the usual ever-changing IP, but he will get used :) .
Thanks for the great advice! I made a snapshot of my Ubuntu instance on Lightsail (as per Simon Tomlinson's great instructions on Facebook), and made a new instance of the same server but with an upgraded plan. Now the new instance, which being a snapshot, is an identical copy of the other functioning instance, isn't working. It's running, but I can't connect to it from Jamulus using the new public ip. Any ideas why?
"Kevin Nortness" knortness@users.sourceforge.net writes:
Any firewall rules or DNS entries or similar tied to the old IP address
in your identical copy?
--
David Kastrup
Recently I've been using a t3.small instance with dedicated tenancy and it has been rock solid for jams with 8 or 10 folks. I noticed a significant difference between using the same instance type with default tenancy. Note that the dedicated tenancy is expensive - you get charged $2 every hour if you have one or more dedicated instances running. For this reason I start the server when we start playing and try to remember to stop it when we are done!
Since testing different platforms costs almost nothing, you may try some cheaper alternative - c5.large is about 0.10$/hour, and likely more than adequate.
I agree. As I download recordings, the major cost for me is data transfer out, rather than on-demand time. I minimise this by compressing the recording folders to .zip before transfer which reduces data transfer volume by about 60%.
I still find that EC2 is much cheaper than Lightsail, with better performance - as long as I turn the instances off between sessions. Lightsail is only better if you have high volumes of data transfer out - so if you're not recording sessions, EC2 is a no-brainer instead. And even if you are, you'd have to record a lot of session-hours for it to be more expensive.
I too record and download, and recently started to zip everything; however, I never thought at transfer costs, thanks for the heads up (though my monthly bill is negligible). I know a fixed cost is the EBS, but affordable in the sizes we need if we delete recordings. By the way, I recently developed a web interface to toggle recording and download zips (check here: https://sourceforge.net/p/llcon/discussion/software/thread/4288b44c95/ ).
I've tried three different servers: A lightsail instance, another Lightsail instance with more processor power, and an EC2. All three are running and can connect to Jamulus. The bubbling and dropouts make the experience utterly useless, however. I'm beginning to think the problem is somewhere on my end. A question: If there were a firewall/port etc. issue, wouldn't it not work at all, or would that create a bottleneck that might be causing these artifacts? I'm beginning to suspect that the main modem which my router is connected to via ethernet (and which is owned by my landlord and is not being made accessible to me) might be the culprit. My router has (i believe) all the necessary port forwarding and firewall rules in place- because again, I can connect to Jamulus, and everything works fine... except for the gawdawful bubbling and audio dropouts. And by the way, I can turn the buffers all the way up with no change in the bubbling or dropouts. In fact, no change in packet size, audio quality, etc. makes any difference.
"Kevin Nortness" knortness@users.sourceforge.net writes:
It would not work at all.
That may well be the case. One of our orchestra members has a cable
modem and that was responsible for dropping and retransmitting an insane
number of packets (possibly because of being wired up without proper
line termination everywhere). A newer cable modem helped. Frequent
dropouts are consistent with retransmission: for a TCP stream that can
tolerate a certain amount of latency, this is mostly transparent. For
just-in-time stuff at high bandwidth, it becomes very noticeable. It is
a pity that you cannot access the router. Any chance to get your own
line?
You need absolutely zero rules in place at the client side.
Prioritising traffic to Jamulus ports may help a bit when the upstream
is saturated, but it's not really making a significant difference in
overall behavior.
I'm currently with Ionos in Germany, and the last rehearsal that went
reasonably well (but not without problems) was on a 12 vCPU plan
(distributed across 3 processors). On Friday I'll check out the largest
baremetal in my current plan which has just 4 cores. Because setup time
alone is announced at 20 minutes, I'll not test in advance. My hope is
that using baremetal will give me realtime priorities (which I
apparently don't have on the vCPUs) in which case the tradeoff of less
power versus proper priorisation of the power should be a net win. I
expect this to consistently either run comparatively smoothly or
comparatively horribly with 6 clients, with not a lot of potential for
in-between.
Not yet checked other providers: regarding the ping times, EC2 in
Frankfurt does not seem like the worst choice for me either.
--
David Kastrup