Hughesnet Community

Latency highly variable but bad for simple browsing - several seconds regularly

cancel
Showing results for 
Search instead for 
Did you mean: 
RandyPAlex
New Poster

Latency highly variable but bad for simple browsing - several seconds regularly

 

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.

RA_latency_201912161913.PNGRA_latency_201912161911.PNGRA_latency_graphs_20191216_1922.png

60 REPLIES 60

The details look good -- there does not appear to be any great packet loss or latency going over the satellite even though the test was run in the middle of peak time in December.  I am guessing you have an excellent beam since only the time interval for 10:00 - 10:05 pm Eastern flagged RTT, and the time on the graph was 9:45 pm.

 

The 911ms avg is really good for 9:45pm -- 600ms is pretty much the best under perfect conditions as these fine folks have mentioned.

 

The graph is a bit of a mystery -- two of the lines look good and the others swing around.  Can you tell the site for each line?

 

I do not know enough about how that test runs -- if it runs 20 pings in a row to a single site, then the result is probably meaningless as random congestion at peak time can make a graph like that.  The two good lines would have been free of random congestion when the test for them was running.

 

On the other hand, if a ping is tested against each site, then the process repeated, then that could indicate that only certain sites are impacted by high latency and traceroutes might show what is going on if you can find out what sites go to each line.  If this is happening, maybe Level3 routes traffic to certain sites through China 🙂

 

 

 

 

My guess is that your equipment is good, and that there is not anything that HughesNet can really address, but maybe @MarkJFine can assist with some traceroutes?  I am on the same gateway as you, so perhaps we can compare a traceroute to confirm we are getting the same result and that Mark, who I think is on a different gateway, gets a different result.  This might show that maybe routing to only some destinations from CHY is the problem? 

 

What do you think Mark?

Sorry, I had missed your reply Mark, but I think I had the same thought as you.  Here is my traceroute, and I think his should be the same as mine as we are both CHY and yours will be a bit different?  My times for hops that were not ignored seem good, but of course 9 am is not peak time....

 

tracert.png

4.34.50.9 is the gateway's provider - registered as Level 3 Communications Inc., but bought by CenturyLink. Chances are you're getting their infamous 1-minute-plus intermittent gaps in service.

 

More info: I've found that the hop just past the inital one into CL's network all time out. That could just mean they reject ICMPs. In your trace, you're already well into Microsoft's network when you get the timeouts in hop 11 and those timeout all the time. I think MS purposely routes ICMPs to rattle around the network until they die.

 

 The ones that are showing in your trace look pretty much as you'd expect for satellite. The hops that are really goofing up in their backbone are the ones that rDNS and have at least one time showing and one asterisk (I see you don't have one of those) but don't fully time out every time.


* Disclaimer: I am a HughesNet customer and not a HughesNet employee. All of my comments are my own and do not necessarily represent HughesNet in any way.

Yeah, I thought the times looked good.  I have never noticed a one minute gap -- I use a timed job to grab router logs and prepare them as a graph every day to review what happened, and that kind of latency should have shown up.  Could it depend on the destination?

 

A few years ago I just had to watch for my niece's and nephew's kids tearing around my lawn on a four wheeler, now I have to monitor my internet and WiFi like a hawk since their kids will sneak an 'XboxOne' or a 'PS4' in and those things can chew through bandwidth and GB voraciously like a hungry bear through the wire on my chicken coop.

 

It seems like it's totally random except that it seems to be more likely when I see a high volume of Chinese activity in my web logs.


* Disclaimer: I am a HughesNet customer and not a HughesNet employee. All of my comments are my own and do not necessarily represent HughesNet in any way.
GabeU
Distinguished Professor IV

@MarkJFine 

 

Is the gateway's provider always the first line after the HughesNet related ones?

Should be, because that's the gateway's exit point.


* Disclaimer: I am a HughesNet customer and not a HughesNet employee. All of my comments are my own and do not necessarily represent HughesNet in any way.

Maybe I am a little slow on the uptake, but I thought I could run the same latency test as the original poster.  I had not noticed testmy had it before, but I guess it is new since they have not corrected the misspellings yet.

 

Anyway, I noticed they do repeat all tests for the same site in a row, so temporary bursts of congestion can produce a graph where some sites look good and others bad.  Having a test for each site repeated with some time between is probably better at leveling the effect of random bursts of traffic.  One of the settings looks like it might do that, but I did not try.

 

I think my results are in line with this time of day, and his graph results being run at peak time are probably typical for peak time.  Since we are the same gateway (CHY), we probably get similar results except for perhaps some variance due to our different beams of which neither appears to me to be overloaded.

 

Any thoughts from the old hands on this?  What are the details regarding the CHY gateway you have heard?  I jumped in here because I use that gateway and it seemed to be working pretty good for me aside from a short outage the early morning of Dec. 6 which could have been a scheduled upgrade if not for odd hiccups right before the start.

 

testmylatency.png

Here's the thing that bothers me about off-network latency tests: You're basically testing the latency between you and their server, using their processing, which is highly dependent on several other factors.

 

To the average user that doesn't understand networking, it would almost certainly and incorrectly be interpreted as a HughesNet latency, when in fact that's only a part of it.

 

It does not include, nor does it show:
1. Any other part of the path that may be contributing (including CenturyLink and beyond).

2. any possible processing delays or congestion on TestMy's part.

 

Bottom line: The only answer they can possibly give is something more than the actual number, which is not really a good thing. As we've seen, CL can be a major contributor at a rate that's much greater than HughesNet's speed-of-light long-distance transmission latency.

 

Edit: If you're looking to assess HughesNet's internal latency, the Terminal Connectivity test in the SCC or a simple traceroute the gateway's provider can answer that. Can also compare that to a traceroute to one of the TestMy servers' IP - you can find it by doing an rDNS or simple host command.


* Disclaimer: I am a HughesNet customer and not a HughesNet employee. All of my comments are my own and do not necessarily represent HughesNet in any way.

Here's an example. Did a test using the LA server because it's closest to San Diego, where my gateway is.

 

The LA server is lax.testmy.net (as they say on their test) or 144.202.123.145.

 

When I use HughesNet's connectivity test, I get an average of 602mS to San Diego (563min to 650max).

 

When I use TestMy's latency test, I get an average of "1597mS to LA, 32% deviation (508.9mS)", whatever that means.

 

So there's roughly a difference of around an entire second between HN's SD gateway and TestMy's LA server.

 

The traceroute (a real mess, btw), looks like this:
Screen Shot 2019-12-19 at 1.53.42 PM.jpg

 

In sharp contrast, the actual latency to LA seems to be a lot less (by ~500mS) that what TestMy is reporting, and TestMy doesn't really tell me where the latency is. The traceroute seems to indicate it's somewhere between hop 7 and TestMy, but I have no idea where.


My only conclusion is that latency to SDO is around 600mS, latency from SDO to LA is another 500mS, and TestMy seems adding another 500mS in processing time: 600+500+500 = 1600 (or 1597mS in this case).


* Disclaimer: I am a HughesNet customer and not a HughesNet employee. All of my comments are my own and do not necessarily represent HughesNet in any way.

Yes, excellent points, which is why I mostly just give that screen a look over, using the drill down on the check or X to get details and scroll way down to 'RTT Diagnostic Statistics' section if I am really dying to know the ms.

 

I suppose using traceroute, then capturing a repeating ping to that step after the sat jump can give a good idea of how the number changes with time of day...maybe.

 

lax.testmy.net.png

 

>ping 2001:5b0:4600:fffa::105 -t

Pinging 2001:5b0:4600:fffa::105 with 32 bytes of data:
Reply from 2001:5b0:4600:fffa::105: time=639ms
Reply from 2001:5b0:4600:fffa::105: time=633ms
Reply from 2001:5b0:4600:fffa::105: time=619ms
Reply from 2001:5b0:4600:fffa::105: time=619ms
Reply from 2001:5b0:4600:fffa::105: time=585ms
Reply from 2001:5b0:4600:fffa::105: time=610ms
Reply from 2001:5b0:4600:fffa::105: time=585ms
Reply from 2001:5b0:4600:fffa::105: time=620ms
Reply from 2001:5b0:4600:fffa::105: time=608ms
Reply from 2001:5b0:4600:fffa::105: time=664ms
Reply from 2001:5b0:4600:fffa::105: time=600ms
Reply from 2001:5b0:4600:fffa::105: time=633ms

Ping statistics for 2001:5b0:4600:fffa::105:
Packets: Sent = 12, Received = 12, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 585ms, Maximum = 664ms, Average = 617ms
Control-C
^C

 

 

I suppose it could be watched like that?

 

 

 

By the way, I think that lax.testmy.net might have been the one site in that testmy graph I made this morning where there was the big latency. I remember thinking it was funny at the time.

 

 

I am not sure how much this helps the original poster -- he was asking specifically about lag web browsing some site?  Maybe it would be good to just know which site?

 

I was drawn in just because of the mention of the CHY gateway having an issue of some sort, but maybe the issue with level3 is very random, or I move too slow to notice?

 

 

It seems completely random, but again, something must be driving it. Doesn't seem logical that systems just go dormant like that. Typically congestion is a good cause, and I'd put even money on it being an overload of vulnerability probing bots from China.


* Disclaimer: I am a HughesNet customer and not a HughesNet employee. All of my comments are my own and do not necessarily represent HughesNet in any way.

The stats and data only matters to me if it helps get to the root issue of why this tremendously fast bandwidth with 1second lag feels as slow (or worse) than <100ms lag but <1 Mbps bandwith. If the metrics aren't showing it, then it seems we aren't looking at the right metrics. I had to reload this page multiple times tonight. Hughesnet,com took like a 60 seconds to load. The router diagnostics show no RTT errors. Traceroutes look pretty good. Even the latency test iisn't as bad tonight but performance is. Below are trace routes for all the Latency sites while the latency test suite ran. I tagged the two peaks. Each line is a series of consecutive TCP hits to a site. Then the next site same thing done.   I then repeated the process a second time while capturing a wireshark trace to get it all and at the tail end of the trace I hit Hughesnet.com, and Amazon.com.  At the tail end of these pics is the wireshark trace with the TCP messages sorted. Looks like lots of errors, repeats, duplicates, etc. So if something is trashing the messages in transit, no ICMP message would show it and even the TCP ping (Latency test) would only show it to some degere, right?  So now next the data sets...

 


@RandyPAlex wrote:

The stats and data only matters to me if it helps get to the root issue of why this tremendously fast bandwidth with 1second lag feels as slow (or worse) than <100ms lag but <1 Mbps bandwith. If the metrics aren't showing it, then it seems we aren't looking at the right metrics. I had to reload this page multiple times tonight. Hughesnet,com took like a 60 seconds to load. The router diagnostics show no RTT errors. Traceroutes look pretty good. Even the latency test iisn't as bad tonight but performance is. Below are trace routes for all the Latency sites while the latency test suite ran. I tagged the two peaks. Each line is a series of consecutive TCP hits to a site. Then the next site same thing done.   I then repeated the process a second time while capturing a wireshark trace to get it all and at the tail end of the trace I hit Hughesnet.com, and Amazon.com.  At the tail end of these pics is the wireshark trace with the TCP messages sorted. Looks like lots of errors, repeats, duplicates, etc. So if something is trashing the messages in transit, no ICMP message would show it and even the TCP ping (Latency test) would only show it to some degere, right?  So now next the data sets...

 


I didn't see this response -- I probably forgot to hit refresh before posting.  You mentioned you had poor speed loading the testmy page?  It seemed fast to me, GabeU/Mark any ideas?  I am seeing what looks like only mild load and great performance in the middle of the heaviest traffic season, and he seems to see something else.

 

 

Maybe try a testmy bandwidth test to see how choppy his bottom graph is compared to mine?  We are both the same gateway, so just the beams are different, and both appear to be uncongested....

Tracert_Dallas_201912191820.PNGTracert_CO_201912191820.PNGTracert_FL_201912191820.PNGTracert_NY_201912191820.PNGTracert_SF_201912191820.PNGTracert_LAX_201912191820.PNGTracert_Toronto_201912191820.PNGTracert_uk_201912191820.PNGTracert_JP_201912191820.PNGTracert_SG_201912191820.PNGLatency_201912191829-1.pngLatency_201912191829-3.pngTracert_De_201912191820.PNGTracert_Google_201912191820.PNGTracert_Amazon_201912191820.PNGLatency_201912191829-2.pngTracert2_Dallas_201912191840.PNGTracert2_CO_201912191840.PNGTracert2_FL_201912191840.PNGTracert2_NY_201912191840.PNGTracert2_SF_201912191840.PNGTracert2_LAX_201912191840.PNGTracert2_Toronto_201912191840.PNGTracert2_UK_201912191840.PNGTracert2_De_201912191840.PNGTracert2_JP_201912191840.PNGTracert2_SG_201912191840.PNGTracert2_AU_201912191840.PNGTracert2_Cloudflare_201912191840.PNGlatency2-201912191845-1.png

Well that was a real pain! Spent all that time since my last post just attempting to upload the pics. Had to reload so many of those that the site stopped me saying I'd loaded 100 images in the last 24 hours.  

Well tomorrow I'll upload the image of the TCP messages from the wirshark trace. Looks like lots of messages needed to be requested again and many duplicates were flagged. Seems like a lot of churn though individual speeds aren't bad??   

So I get it the latency test doesn't square with things you all see and it doesn't seem to reflect my poor performance either.

Is there a test I can run from my end that you do trust? I hope it is something on my end so that it is fixable. Just let me know what to run, please. 

GabeU
Distinguished Professor IV

@RandyPAlex 

 

Is the problem you're having with all sites or specific ones, or is it even intermittent and not following any particular pattern?  The reason I ask is that some months back I was having a problem with Facebook, with any Facebook page often taking upwards of five or six minutes to finish loading.  The problem eventually solved itself, and I say "solved itself" only because one day I noticed that it was back to normal.  It still takes a little longer to load than many other pages due to all of the junk on it, but it's nothing like it had been.


@RandyPAlex wrote:

...

So I get it the latency test doesn't square with things you all see and it doesn't seem to reflect my poor performance either.

Is there a test I can run from my end that you do trust? I hope it is something on my end so that it is fixable. Just let me know what to run, please. 


Yeah, I could not see a way to distinguish 9am from 9pm, a light traffic time vs heavy traffic time, based on the results of the testmy latency test, so I think it might not be useful yet, or at least not useful with the defaults.

 

I had seen a suggestion once to vary the packet size of a ping trying 1500 or 2500 bytes, as the larger packets present more trouble going through and show issues a bit better -- I had run some things like that in the past to get a feel for how choppy things are, maybe that could show something?  Also, you mentioned the HughesNet site taking like 60 seconds to load?  I tried, and from the click on the link to the finishing of the big image it looked like I was seeing 15 seconds, but my link, time of access, and browser may be different.  Maybe some of the other folks care share what they see?

 

Maybe there are some other factors - the data saver seems to increase latency as well as decrease bandwidth to sites that deliver streaming video, maybe snooze that and see if a test comes out different?  Are you connected directly or using WiFi?  If there is some random interference, the WiFi may have to re-transmit a bunch of packets increasing latency (the data does not get billed twice over the satellite as the retransmit is just between your WiFi and computer -- you see see by comparing the WiFi log with the data usage)

 

 

I did compare the results of my latency on 12/19 this year with the same day in 2018. That is a test result done every few minutes over the course of 24 hours and the average is interesting in that it has dropped from an average over the 24 hours of 937ms to 668ms.  There was far more usage that day on 2018 for me then this year, so maybe the data saver had a bigger thumb on the scale then, but maybe my subjective sense that things feel faster now is related....

 

Perhaps just trying a simple test based on specific things you are seeing as slow and repeating at different times in the day in line with what GabeU suggests?

 

 

 

 

 

@RandyPAlex 

All those traceroutes look fairly normal for satellite and using TestMy is just confusing the issue.

 

I'm beginning to think the problem is part perception and just how web sites are constructed these days: There are literally hundreds of things (html, images, css, javascript, etc.) on a standard web site. That 1-second lag time applies to each one of those things, sometimes serially, because they all have to be downloaded separately.

 

If those things are on-site and/or cached by a content delivery network you might same some time resolving the host name, but you still have to transfer each one of those things, each requiring a different transfer connection.

 

Edit: For example, just this page (which is really, really lean, btw) has:
The main html

2 fonts from fonts.googleapis.com

1 css from header.hughesnet.com

1 icon from community.hughesnet.com

7 javascripts community.hughesnet.com

2 html frames from header.hughesnet.com

2 external htmls from schema.org

3 user icons

----------------

total lag: ~19 seconds.

 

Should also add that those are the total external items. How those 19 seconds are actually distributed depends if they're loaded synchronously or asynchrounously, or if they're above or below the fold, as well as the size of each 'file' - all of which drives when the page actually starts to display.


* Disclaimer: I am a HughesNet customer and not a HughesNet employee. All of my comments are my own and do not necessarily represent HughesNet in any way.
maratsade
Distinguished Professor IV

"I'm beginning to think the problem is part perception and just how web sites are constructed these days"

 

Agreed.