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
maratsade
Distinguished Professor IV

Testmy's great for speed, but their latency test is not reliable for satellite. To check latency, run traceroutes and you'll see that latency's pretty stable and predictable with satellite. What you think is latency is probably congestion. 

I ran a tracert and got back the 600ms ish response as you suggested. But that’s not TCP data, right? Congestion would be apportioned data rate being lower, not lag in response, right?

I click on a link and there is a notable DELAY in response, and when it does respond I get a flood of data. Is that what you’d expect with congestion?

If it is congestion and I run a wireshark trace and look at the TCP data latency i should see a similar 600ms delay but data rate on the returning page throttled to spread the wealth amongst my fellow users on the same beam at this time, right? Congestion wouldn’t result in a ‘site not responding’ message would it?


@RandyPAlex wrote:
I ran a tracert and got back the 600ms ish response as you suggested. But that’s not TCP data, right? Congestion would be apportioned data rate being lower, not lag in response, right?

It could manifest itself in both speed and latency depending on the nature of the congestion and where within the HughesNet system or internet backbone that it resides. Congestion on Gen5 can also appear 'bursty', where the envelope of a speed graph appears somewhat sinusoidal as the congested packets are handled, with your's being handled in-between.


* 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.

I just signed up with HN because my local DSL provider had <1Mbps that would come and go to even worse conditions. I hung in there for several years in expectation that they would replace the DSLAM that was the pinchpoint, but finally gave up. Honestly I could tolerate having only several Mbps steady bandwidth with latency <1 second but latency of several seconds almost all the time and bursts of 25Mbps feels almost the same as 1Mbps with negligible latency.

 

What is the plan to mitigate the effective latency? Where should I send the wireshark trace to support the investigation?


I am also on the Cheyenne gateway, but have not had any noticeable issues recently with either latency or bandwidth. One thing that might be useful is to compare what the HughesNet System Control Center shows as your round trip time for the satellite (RTT). You can see this from this link:

 

http://192.168.0.1/limited.html

 

Under 'Diagnostics' in the menu on the left of this screen is an option for 'Hourly History' which looks like this:

 

 

 

hourly.png

 

3 GMT is 10 PM Eastern, so column 3 (9 pm to 10 pm Eastern) is the peak time for me.  The 'X' for downlink this morning was due to bad weather for me.

 

Each hour is is shown in GMT, rather than your time zone, but each number in the header is a link for a detailed chart that looks like this:

 

detail.png


The link to the detailed chart has a bug in that an '!' is left out of the URL, so you have to edit that in manually to get to the detail page. The Activity box also has a minor bug in that 'Uplink' is just the 'Downlink' data repeated.

 

There is a row for 'RTT' which turns to an 'X' if the round trip time over the satellite is over 2000ms. This time excludes the time at the gateway and Internet so this is useful to see if the satellite is having a large latency only during 'rush hour' due to congestion specifically on your beam, or if something else is going on.

 

If the RTT is only an 'X' during the prime time 'rush hour' then maybe you are seeing congestion on your beam.
If there are no 'X' marks for RTT, then maybe the issue is at the gateway or route to the site.
If the RTT is an 'X' throughout the day, then maybe there is an issue that the support folks can help with.

 

If showing a screen shot of this page hide the account numbers at the top....

 

 

Thanks MrBuster. That is actionable information. I'll take a look at it when I get home tonight. 

maratsade
Distinguished Professor IV

Really? Actionable how?

 

 

RandyPAlex wrote:

 That is actionable information.

Actionable... something I can take action on. Just the literal meaning 'able to take some action'

I can look at my router and help split the dictionary, so to speak. If there are tons of RTT errors it seems that it points to something involved with the satelite exchange. If there are none then it says the lag is in in other half of the dictionary - the ground based portion or the specific site lagging in response. Or did I misunderstand. It is an action that can be taken to move troubleshooting effort forward based on data. Conjecture does none of that. I'm not sure who MrBuster is but I appreciate people sharing concrete things that I can act on that moves problem solving more concretely forward.  

I'd done what I could think of by capturing a few wireshark traces to put data to the TCP lag of the system, whatever the source(s). MrBuster gave me something tangible that helps bring additional data. 

(I didn't even think of the darker overtones that can be implied by "actionable". I didn't mean any of those.)

 

maratsade
Distinguished Professor IV

Oh, i know what the term means. I just wanted to know how this was actionable for you.  You explained how, so cheers! 


@RandyPAlex wrote:

Actionable... something I can take action on. Just the literal meaning 'able to take some action'

I can look at my router and help split the dictionary, so to speak. If there are tons of RTT errors it seems that it points to something involved with the satelite exchange. If there are none then it says the lag is in in other half of the dictionary - the ground based portion or the specific site lagging in response. Or did I misunderstand. It is an action that can be taken to move troubleshooting effort forward based on data. Conjecture does none of that. I'm not sure who MrBuster is but I appreciate people sharing concrete things that I can act on that moves problem solving more concretely forward.  

I'd done what I could think of by capturing a few wireshark traces to put data to the TCP lag of the system, whatever the source(s). MrBuster gave me something tangible that helps bring additional data. 

(I didn't even think of the darker overtones that can be implied by "actionable". I didn't mean any of those.)

 


I think you have the idea.  If your screen looks like image below, then I suspect you may just be seeing congestion on your beam during evening prime time, and things might be better at other times -- hours 1,2,3 are GMT so subtract 5 to get Eastern time as most of beam 49 seems to be Eastern:

hourly - probablycongestion.png

 

 

 

 

If your screen look like the image below, then the issue may be at the gateway or past the gateway.  Since I am also on the same gateway (CHY) and am seeing good performance over the last 24 hours, I would therefore suspect if you are seeing this, then the issue is beyond the HughesNet gateway and traceroute may track down what is happening.

 

hourly - probablyLevel3orGateway.png

 

 

 

If your screen looks more like this image below, then maybe your dish needs aligned or there are trees in the way or something the HughesNet folks can assist with.

 

hourly - probablyDishMisalignedBadWeatheretc.png

 

 

Thanks. I’ll post results.
It occurs to me that unless I have something constantly trying to pull a little bit down then there are no data transactions from which to have round trip transport delays. True?
Does the router itself send periodic packets that would suffice to stimulate the RTT errors if it is substantial?


@RandyPAlex wrote:
Thanks. I’ll post results.
It occurs to me that unless I have something constantly trying to pull a little bit down then there are no data transactions from which to have round trip transport delays. True?
Does the router itself send periodic packets that would suffice to stimulate the RTT errors if it is substantial?

Yes, even when nothing is connected there is some minimal activity (appears to be 2 packets a minute) that allows gathering basic metrics about issues, but as you can imagine, more data used does give a better idea.  I had wondered if this was using my data, but in my testing it appears HughesNet does not count these packets toward your limits as far as I can tell since 120 GSE Packets an hour should use up 1 MByte over a couple of hours causing a minimal measurable usage and I do not see that happening when the box is on with no devices over the course of a day.

 

In the posted pic, the weather event from 3-4 am (9 GMT) was recorded as a downlink issue, but no devices were using data, and the RTT I shown would have been 9pm-10pm and I was not using the system.

 

I think starting from here helps to know if there is even a problem before getting deep into testing.

 

 

GabeU
Distinguished Professor IV

@MrBuster 

 

Just out of pure curiosity, how were you able to alter those pics of the same time intervals?  I thought maybe paint, but that would be FAR too tedious.


@GabeU wrote:

@MrBuster 

 

Just out of pure curiosity, how were you able to alter those pics of the same time intervals?  I thought maybe paint, but that would be FAR too tedious.


Yeah -- I used paint, draw a rectangle around an X then ctrl-drag to each spot.  With a little practice, even a person with shaky hands like me can manage as long as you do not look too close 🙂 

 

HughesNet seems to offer a lot of data salted away under weird places and odd links which are very handy for tracking things down, but I can see how giving an explanation can be hard.  I used a different satellite internet before and they did not seem to have as much detail available.

 

 

GabeU
Distinguished Professor IV


@MrBuster wrote:

Yeah -- I used paint, draw a rectangle around an X then ctrl-drag to each spot.  With a little practice, even a person with shaky hands like me can manage as long as you do not look too close 🙂 

HughesNet seems to offer a lot of data salted away under weird places and odd links which are very handy for tracking things down, but I can see how giving an explanation can be hard.  I used a different satellite internet before and they did not seem to have as much detail available.


I appluad your tenacity for the purpose of helping others.

@MrBuster 

Have to say, that's probably the best explanation I've seen on how to interpret the diagnostics page. Many people tend to ignore those. This may be the first time I've seen it put to good use. 👍🏼


* 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 wrote:

@MrBuster 

Have to say, that's probably the best explanation I've seen on how to interpret the diagnostics page. Many people tend to ignore those. This may be the first time I've seen it put to good use. 👍🏼


Agreed. I also had no idea what RTT stood for, but even further, what it meant on that table.

Here is what she looks like currently. Not much of an issue with RTT but some of the experienced latency is quite significant. It showed nothing when I started an hour or so ago.diagnostic_history_201912171944GMT-5.PNG

 

It wasn't until I ran the latency test on testmy.net that it stimulated something. HN congestion_201912172217.PNG

 

 

 

 

 

If you read what it says in the latency test, it makes sense to me that it is a better gage of web page latency (TCP; layer 4) than ICMP layer 3 messages like tracert and ping.

It feels more like what I experience in usage too. TCP latency to multiple sites, 20 reps each.TCP latency to multiple sites, 20 reps each.
Latency_201912172212.PNG

 

Since I don't just believe what I read, I ran tracert to many of those same sites in parallel so it could be captured in the wireshark trace I was running. The pcapng file has this kind of gorey detail on the comms through my ethernet port:Wireshark pic 201912172233.PNG

 

Wireshark is a free network analysis tool (https://www.wireshark.org/) with awesome trace capability. 

Is anybody at Hughesnet interested in looking at my trace to see what the source of my frustratingly laggy performance is? I'd be glad to email it to you.

Ultimately, the experience of the user is what HN delivers, not statistics, but stats help us troubleshoot techical issues. My router seems to say I don't have RTT issues (at least not bad enough to trigger the built in fault) and tracert shows quite good response (albeit optimistic layer 3 and below), SO... whatever my issue is seems to be  in the TCP layer above it or in the gateway or the external site. Since I captured tracerts to those same sites and they too show <1000ms speeds unless they just bombed ("*"), this would say the connection to them is fast enough (by ICMP judgement). And yet TCP is laggy. All the data is in the PCAPNG file.   I'm really not trying to be a jerk. I'm just an engineer looking for answers based on data. 

 

I appreciate any suggestions out there that lead to greater insight on this issue.

Since this is a community tech support site I assume there is only so much that kind volunteers can do as opposed to paid HN employees if I call tech support there. I guess that is my next step. 

I can't unfurl what's going on in that wireshark trace. But it's looking more and more like it's Century Link causing the problem. If you do a simple traceroute to something common like microsoft.com and post it here I can probably tell by the 4th or 5th hop if that's it.


* 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.