My speeds seem to be quite good but the latency is CRAZY bad. I ran latency tests on testmy.net. I'm not into gaming or anything, and preloading of streaming usually is sufficient with the high bandwidth (previous ISP was 1Mbps on a good day), but the latency is killing me for simple browsing. I even had a reply that Hughesnet is not responding it was so bad. I'm new with HN so I'm assuming there is something that can be adjusted in my modem to help with this. The following graphs were taken while connected by ethernet cable to the modem and my wifi disabled. This is just not right, right??
Speeds seem to be quite good but the latency is CRAZY bad. I ran latency tests on testmy.net. I'm not into gaming or anything, and preloading of streaming usually is sufficient with the high bandwidth (previous ISP was 1Mbps on a good day), but the latency is killing me for simple browsing. I even had a reply that Hughesnet is not responding it was so bad. I'm new with HN so I'm assuming there is something that can be adjusted in my modem to help with this. The following graphs were taken while connected by ethernet cable to the modem and my wifi disabled. This is just not right, right?? PLEASE say there is something that can be done.
Also thinking we shouldn't conflate this with the larger CenturyLink problem, which is gaps in the minutes, not seconds.
Well, I thought I would run that testmy latency test to see how it differs for me in peak prime time, but it looks to me like this test really does not work well at all since the effect of the additional load of prime time really is not clearly reflected.
My average ping is similar(?) -- and how can the average be near 650 if there was a deviation close to 300? If there was a ping of 950, it would take a lot of 600ms pings to pull the average down to 650, right? I am guessing this is off or that this is stating things are choppier (busier), but that the average ping has not come up like I normally expect. Also, in looking at the scale of sites, really nothing has changed -- almost as if the latency of a more crowded evening satellite beam was unmeasurable compared to the backbone traffic crowding that happens at any time. Oh, and lax was not available either.
The times on this test seem to imply my beam is empty, unless the deviation is the only useful clue. I think you guys were correct that this test is not too reliable at this point.
I estimate the load on my beam by checking pings all the time -- a choppy bunch means busy, and flat means no one is on the system without really needing to do a bandwidth test to know. Maybe this is what it is showing and I don't know how to read this graph, but it seems easier to see a sequence of pings going all over with a rising average to realize things are getting busy.
Looking at the choppy graph on the bandwidth test does a better job of revealing the traffic out there, but the speed does seem good for this time at night -- Did CHY get upgrades earlier this month? It seems to be performing better than I expect for December prime time, and the last couple weeks have seemed strong. What was that Dec. 6th morning outage? Could that have been a quick bunch of upgrades? Did someone spy activity in the middle of the night and assume there were big problems being fixed?
Looking at the choppy graph on the bandwidth test does a better job of revealing the traffic out there, but the speed does seem good for this time at night
This is what I've tended to rely on for evidence of congestion as well. The choppier the heavier, though it doesn't always seem to affect my speed in the same way. With all the other things out there that can affect speed, though, I wouldn't really expect it to.
I've no doubt you're both serviced by Level3 and are likely seeing their intermittent 1-minute lag gaps. I just want to verify by looking at the IPs and times in a single threaded traceroute, which is easier to read than something multiplexed.
And speaking of routing through China... Realize you were facetious, but I actually theorize that the reverse is what's happening: There are massive constant internet scans from 0.0.0.0 thru 255.255.255.255 coming from China, HK, and Taiwan that might be tying up CL's network resources (most of it comes from Tencent and Alibaba clouds, but they have also taken over several domestic cloud services on Amazon, Google, Oracle, etc. as well). One such site probe can contain over 1000 vulnerability tests and can last for about 6-10 minutes on a reasonable connection. Imagine that going through a singularly managed backbone if done en masse.
I see these in both my access logs daily and have a majority of CN, HK, and TW blocked because of it.
Chances are the distance between you and the satellite, plus the distance between the satellite and the ground station on the west coast is sufficient to create an approximate 525mS (a little more than half a second) transmission time. That's as fast as a 20GHz radio signal can travel at the speed of light.
Now add to that any processing delays at the ground station due to any congestion, as well as any transmission delays in the route generated by the ground station's internet provider.
If you're looking to mitigate lag times lower than this, good luck with that.
The latency with satellite internet will always be at least 600ms or so. But, like maratsade said, it's likely that the problem you're experiencing is congestion. Even if the amount of latency testmy is reflecting was accurate, it would still only be about 1.2 seconds of delay from onset of action.
You may also want to run some speed tests using this protocol to see what you're getting.
Congestion is still likely to be at least a part of the problem, but you may also be experiencing some of the issues being caused by Century Link downstream. @MarkJFine may have some ideas as to whether the latter could be contributing to the problem. He may reply with him now being tagged.
Do you know what satellite and gateway you're on? If not, what do you see for your IPGW Gateway Association State string on this page? Specifically the characters before HNSIGW, like in the following pic?
This shows what you need?
Yes, it does. The Cheyenne gateway has apparently be having some issues. If/when Mark replies, he may have some ideas or suggestions, though it may just be a waiting game.
It's definitiely Cheyenne, but didn't think that problem was a latency problem and thought those problems were cleared up.
Can't remember if Cheyenne is handled by CenturyLink or not, but chances are that it is because they've basically bought everyone else, including Level3 and Qwest. Can tell by the IP in hop 4 or 5 (whatever follows the last DirecWay hop out of the system and into the backbone) in a basic traceroute.
I ran a wireshark trace while I went to Amazon.com. While I waited for it to respond I started and ran a tracert to 18.104.22.168. The Amazon page stopped filling soon after I closed the cmd window from the tracert. I assume amazon is a bit busy on their end this time of year so I will run another wireshark trace for the sending of this reply. Certainly this site isn't going to be bogged down. To make it interesting I'll also try to hit red.com in that same trace just so it isn't dependent on any single site response.
Is there a way for me to upload the pcapng files to the forum or send to you via email?
The latency test on testmy.net is not a ICMP message test but uses TCP messages so it should be a fair representation of the dynamics for browsing response, right? In this latest wireshark trace I captured during the last post sending (quite quick response) and the Red.com hit (quite slow response) I included a latency test to Dalles and got a few delays approaching 3 seconds.
I'm sure these will be helpful since it provides empirical data of the dynamics and removes the conjecture. Where should I send the traces for analysis by your experts?
My speeds seem to be quite good but the latency is CRAZY bad.
I'm having the same problem you are. So let me tell you how it all shook out.
You're going to have a near impossible time getting HughesNet to admit there is a problem. Talk to their first level tech support and they will follow the script and eventually turn you over to engineering. That is, even if you can get past them. Their first line of defense will be that the latency you are experiencing is normal. (Yes, they will really tell you that!)
Next is advanced support. Some will try to help, but ultimately they will fall back on to that "everything is normal" line. You're not going to get anywhere with them.
Laghingly, one mod on this forum even told me to go find another ISP if I didn't like it. (He was reported)
I had to climb very high up the ladder to get a real response. But I did get a response.
They are starting (just starting, mind you!) to look into an issue of a data clog by the infamous CenturyLink. Other than that, they can try realigning your dish or switching you to a different satellite.
Beyond that, you're kind of stuck.
That was my choice. They sent a tech out to realign the dish. (They are still working on that. The tech brought the wrong equipment so he has to come back.) Or they can switch me to a different, overloaded satellite. So if the realignment doesn't work out, my choice is high latency or slow speeds.
Another possibility is bad gateway management or bad traffic shaping, but based on the data, it really looks like a data clog just outside the gateway.
As of this moment, HughesNet is not acknowledging that. But I did get them to look at it. At least, that was what the higher-up told me. He seemed honest, so I will give him the benefit of the doubt.
Wish I had better news. But there it is.
Laghingly, one mod on this forum even told me to go find another ISP if I didn't like it. (He was reported)
No, he didn't. That's not at all what was said.
I follow the line of reasoning about the "apparent" slow speed but find it EXTREMELY disturbing. However it got me thinking it through a little differently. For the satelite to load a page in the same total time as DSL, the satelite data rate speed must be fast enough to more than make up for the difference in the latency betweem the two (which is HUGE):
Total load time for a page is roughly
t = (page bytes) * (data rate) + (number of serial requests) * latency.
So i ran some numbers calculating where the page load time is the same for satelite and DSL given the specifid bandwidth and latency numbers shown. Basically, the satelite wins on pages that have few serial requests and large amounts of data. DSL wins for pages with little data or lots of sequential requests - even really slow DSL. Here are the break even points for a few scenarios:
So physics is physics, you can't make the signals go faster than light. Satelite WILL have very high latency until they put them in lower orbits. The latency delay is enough on normal days that it can result in web browsing being slower than even lousy DSL (that normally has much lower latency).
The latency will make gaming impossible (they inform you of this) and VPN connections probably are unusable thinking they lost connection due to the latency (but the sales people ask about that too). They don't mention stutteringly delivered browsing and an often EFFECTIVE bandwidth that is much closer to low speed DSL. It isn't too bad for streaming videos as long as the app has significant buffering, but you may get a "lost internet connection" if you hit it just wrong. It is great for loading large files.
Once this all started to click I stumbled on the following article that I REALLY wish I'd have found a month ago before I had satelite service installed. https://www.howtogeek.com/138771/htg-explains-how-latency-can-make-even-fast-internet-connections-fe...
I believe there is a small window of time after service is installed in which you can cancel and NOT have to pay the $400 cancelation fee. Anybody know where that is stated? Is it 20 days or 30 days? I hope I'm not outside the narrow window.
I guess I should explain the grid of figures a bit.
Top part: Satelite with 25Mbps bandwidth and 600ms latency (near ideal conditions from what I hear) is compared to DSL with only 1 Mbps bandwidth and a fairly normal latency of 50ms.
-If you have a page that loads EVERYTHING with a single request (or all requests virtually simultaneously), if the page requests a total of <0.58Mbits then DSL will load it faster than satelite. More data and satelite will load it faster than DSL. If the page is 0.58Mbits it will load by either method in 0.63 sec.
-If you have a page that loads EVERYTHING with no more than three sequential requests and otherwise all requests are simultaneous, if the page requests a total of <1.72Mbits DSL will be faster than satelite. More data and satelite will load it faster than DSL. If the page is 1.72Mbits it will load by either method in 1.87 seconds.
-If you have a page that loads everything with no more than 7 sequential requests and otherwise all requests are simultaneous, if the page requests a total of <4Mbits DSL will be aster than satelite. More data and satelite will load faster than DSL. If the page is 4Mbits either method will load it in 4.36 seconds.
Lower part: Satelite with 16Mbps bandwidth and 800ms latency (near ideal conditions from what I hear) is compared to DSL with only 1 Mbps bandwidth and a bit slower latency of 70ms.
Same scenarios as earlier but DSL wins on pages with even higher amounts of data.
(Extrapolating: If satelite latency is 1200ms (most people calling that not bad during congestion), satellite wins only if data in the page is about double what is shown in th upper part.) It is VERY easy for me to now see how this latency made it feel like I had worse bandwidth that the lousy 1Mbps that I left.
Does Hughesnet have plans for lower orbit satelites? Halving the latency would dramatically reduce how much stuttering would be perceived in delivery (due to sequential requests compounding the effect).
Lower part: Satelite with 16Mbps bandwidth and 800ms latency (near ideal conditions from what I hear)...
Oops, I meant "(more reasonable bandwith and latency though still great for high congestion times from what I hear)"
"Does Hughesnet have plans for lower orbit satelites?"
They're involved. In August of this year they signed a contract for $190M with OneWeb for the production of the gateway sites for OneWeb's LEOs, with multiple tracking satellite access points to support operation and handoff of high-speed traffic between satellites.