Since we have installed the Gen 5 service at our site, we have had nothing but problems. We are trying to use this service to feed an audio stream to a licensed FM broadcast transmitter. There is only one device connected to port 1 on the modem. It's a Barix Extreamer mp3 decoder. Nothing else hooked up using any data whatsoever. Data use isn't an issue, throughput is. Wireless is on, but fully secured.The recieving unit at the transmitter (on HughesNet) looks for a static IP and port at our studio (fiber internet- 8 kbps+) and connects. We send the mp3 stream at 128k, 44.1. It does not matter though how low we set the bitrate, I've even tried 8 bit, 16k mono. It doesn't matter. The latency is so bad on packet delivery, especially between 6 PM and midnight (eastern.) Even setting a full two seconds latency on the Barix, there is still constant jitter. It is un-listenable.
It's now the 4th of July weekend, and it has been this way now day and night the past three days (Fri-Sat-Sun.) The issue fully seems to me to be a peak usage low performance issue. We need mission-critical performance 24/7. Sometimes, and really meaning just every so often, during the day, it is OK.
This is a remote site on a high hill where the HughesNet is installed, and I do not have physical access to the site most of the time. Yes we know, any bad weather or storms, we are out. We can deal with that. But this is happening constantly without a cloud in the sky.
We have called tech several times, and even had a site visit just a few days ago. Both dish radio and modem were replaced. The dish is in the sweet spot according to tech. Signal constant at 112-113. Without a static IP and / or remote admin access to the modem / equipment there. I cannot run speed tests when the problem is occurring there.
I did run a traceroute to the IP address that the Barix studio unit on the headend is telling me that the remote unit is connecting from. There are like 13 different hops. Seems much.
There should be no reason for this poor performance on Gen5. Can you help? Can I get a more direct route for my packets? or can there be anything done to let this stream get through faster? Last call I made to support- one night during poor streaming audio jitter and dropouts, the tech told me (even after escalation to engineering) that all looked normal. That cannot be.
Before we went live, I bench tested this setup at my home, (different provider where throughput speeds are a lot lower,) and ran the stream for 48 hours without the first glitch. Please help me try to resolve this.
Jitter and high latency is a normal thing on satellite, can't get around it. The only thing you can do is make sure you are pointed at Jupiter II by going to System Information when you access the modem, and look under Satellite Name, it should say Echostar-19-NAD. The only time an installer will point to J1 is if you are in one of the few areas where J2 isn't available.
You might want to try Disabling Web-Acceleration to see if that helps any, as well as ensure you are not using a wifi network if at all possible.
Web acceleration is off. And sat is E-19. All confirmed by tech on phone.The wireless network(s) broadcast, but they are locked down with super-secure password-no outside access. I could shut them totally off when I return to the remote site, but really? That much problems from just having the wifi on and not connected?
What I do not understand- is that there are the times that the stream I send is received perfectly. Like July 5th most all day, and July 7th...All day. However most any other time, especially beginning in the early evenings, the loss is significant, and the speeds slow incredibly. It's like the NOC throws some kind of 'kill-speed' switch.
The whole Friday-Saturday-Sunday-Monday-Tuesday of the 4th of July was a wash, and anytime night and day now for the past several days. This is unacceptable.
This is what I thought was Business / Enterprise Class. It is 'Mission-Critical' service we require. If you can make it work for 5-6 hours without a glitch, there should be some setting or route that my data can be sent that it should work 24-7 with less than 2000 ms latency. The packets arrive, but way too late for my buffering. And for my mp3 decoder, my max buffer is 2074 ms. I'm very unhappy with support- no real help- says all is fine on their end. Not a chance. I could understand if I simultaneously had a whole enterprise running on the HT2000. but it's just one simple device.
I can bring the unit home, and send the same stream with the exact same settings to my home ISP- 25 hours runtime, no glitches at all. I have 6 Mbps DSL. The one difference are that the ISP's are the same on both ends- (obviously a shorter packet route.)
The 18 Mbps HughesNet at the tower site is worthless to me if the latency is so bad that I can't run this one live stream without constant jittering and drops. Only problem is- that onsite at the location this needs to be, that there are no wired internet options available. If we can't find a way to make it work, we are planning to lose the HN quickly, and try a 15 mile wireless IP radio shot, or a different ISP to carry the audio to another site to be able to do a 7 mile hop from there to the far end with either the IP radio, or on an existing STL system.
I just have to get this fixed somehow.
Hughesnet isn't going to create a dedicated route for one customer, they don't own any backbone infrastructure, so once the data leaves their gateway, it's upto the peering partners/networks.
The simple fact is, the jitter will always exist, and you will always have high latency. Not sure why you would have 2000ms latency though, what does the terminal report for latency when doing a Connectivity Test? There is only one platform where anyone could possibly be seeing 2000ms frequently, and that's Spaceway3/HN9000....
If you are an SME customer, there's not much of anything anyone here can do for you, this community is geared more towards residential subscriber accounts.
Suppose I'll keep trying. Otherwise, just consider these posts somewhat of a frustration-venting rant. Up to this point the service is just not what I expected at all. Thanks anyway. I'm sure it works for a lot of folks, it just isn't up to task for what we are trying to accomplish with it, apparently.