HughesNet Community

The all to familiar problem, slow - slow - slow

cancel
Showing results for 
Search instead for 
Did you mean: 
hamradio
Senior

The all to familiar problem, slow - slow - slow

I have complained about the throughput speed before and there was no real solution  Sometimes downloads are near what one would / should expect, but most often very unsatisfactory.    No way for me to prove it, but all evidence available points to Hughsnet gateway bottlenecks.    Sometimes the download speed may be (sort of) OK, but the actual throughput is usually very slow due to "waiting"  - periods of inactivity in responding to a request.

I have a 101 signal strength, plenty of data, recently power-off reset the modem, Ethernet connection to moder, ect.  Near dialup true throughput persists in spite of the indicated fast speeds by testmy.net.  

Also, Testmy.net (recommended by HN) does not seem to be reporting acturately.   The most recent run indicated the speed topped out at 98Mbs. It has reported speeds in excess of  200 Mbps Yeah, right! 

https://testmy.net/db/62oQU7mpa      Here are others:  https://testmy.net/db/UDZZeu0Q3   https://testmy.net/db/-aL2Zg~-R

A test by speedof.me (HTML5 Test) produced results that reflect what throughput speed I actually receive:

https://i.speedof.me/190925232454-2087

Sometimes the crazy high latency reported in this test are more a more realistic value, around 660.  However, the speed is still slow.

My question is will HN ever fix the problem that I (and many, many others) are plagued with?

 

Thanks,

Woody  -  KZ4AK

 

 

 

https://i.speedof.me/190925232454-2087

85 REPLIES 85
maratsade
Distinguished Professor IV

"If you're working with us in the community or social media, only testmy.net results are accepted to be considered for escalation to corporate engineering."

 

https://community.hughesnet.com/t5/Tech-Support/Think-you-have-slow-speeds/td-p/110034

 

You may also want to post a link to your Testmy.net results page instead of to individual tests. 

 

hamradio wrote:

I have complained about the throughput speed before and there was no real solution  Sometimes downloads are near what one would / should expect, but most often very unsatisfactory.    No way for me to prove it, but all evidence available points to Hughsnet gateway bottlenecks.    Sometimes the download speed may be (sort of) OK, but the actual throughput is usually very slow due to "waiting"  - periods of inactivity in responding to a request.

I have a 101 signal strength, plenty of data, recently power-off reset the modem, Ethernet connection to moder, ect.  Near dialup true throughput persists in spite of the indicated fast speeds by testmy.net.  

Also, Testmy.net (recommended by HN) does not seem to be reporting acturately.   The most recent run indicated the speed topped out at 98Mbs. It has reported speeds in excess of  200 Mbps Yeah, right! 

https://testmy.net/db/62oQU7mpa      Here are others:  https://testmy.net/db/UDZZeu0Q3   https://testmy.net/db/-aL2Zg~-R

A test by speedof.me (HTML5 Test) produced results that reflect what throughput speed I actually receive:

https://i.speedof.me/190925232454-2087

Sometimes the crazy high latency reported in this test are more a more realistic value, around 660.  However, the speed is still slow.

My question is will HN ever fix the problem that I (and many, many others) are plagued with?

 

Thanks,

Woody  -  KZ4AK

 

 

 

https://i.speedof.me/190925232454-2087


 

Perhaps this...

https://testmy.net/compID/8963032529

An interesting observation:  Although I always try (not perfect, you know) to ask for 25MB tests, that is not what is sometimes reported.  Odd...???

_W_

GabeU
Distinguished Professor IV

@hamradio 

 

It's because Comp IDs can be shared by multiple people, so you may be seeing other people's results, as well.  It's because of the dynamically changing, shared IP addresses assigned by HughesNet.  

 

This is why, when testing for troubleshooting purposes, creating an account and running the tests under that account is needed.  This way, when the reps/engineers click on the Results page URL posted by the tester, they only see that person's test results.


Ryzen 5 3400G | MSI B450M Pro-M2 MAX | 16GB Corsair Vengeance DDR4 3000 | XPG SX8200 Pro 512GB NVMe | Windows 10 Pro

All well and good, but the testmy.net results are secondary.  The horrible throughput is the primary problem and has been well established.  My question is why and (if) when HN will do something about that.  ...Even viewing a small youtube video can be nearly as much buffering time as actual content...  Another example, downloading a PDF can take a very long time - Watching the download data rate shows long periods when nothing is happening, then it resumes data transfer.

_W_

GabeU
Distinguished Professor IV

@hamradio 

 

When I have issues with file downloads, whatever type they may be, I first try rebooting (from the SCC) or power cycling the modem, and if that doesn't help, I wait a little while, then try again.  Granted, this doesn't always solve the problem at the time that I'd like it to be solved, but it often helps, or at least it does for me.


Ryzen 5 3400G | MSI B450M Pro-M2 MAX | 16GB Corsair Vengeance DDR4 3000 | XPG SX8200 Pro 512GB NVMe | Windows 10 Pro

Been there, done that....  It does not help.  The only remedy is to wait hours or days and try again - and maybe get lucky.  This further points to a major issue at HN.   The only other reason, given all the observations, is that there is some possibly my HN transmitter is faulty and low in power.   However, that is not too likely when the delay seems to be when waiting on a response from HN, getting slow file downloads, and constant youtube buffering.

_W_

GabeU
Distinguished Professor IV

@Myztical 

 

And I mean no offense with this, but being a former HughesNet installer doesn't mean you know everything about HughesNet's service that you think you do.  The information below is factual and correct.   

 

Testmy.net assigns Comp ID by IP addresses, which, in the case of HughesNet, are both shared, and dynamically changing.  Residential subscribers do not have static IPs.  This is EXACTLY why testmy.net Comp IDs can, and very often do, show tests from multiple HughesNet subscribers, and this is why Result URLs, not Comp IDs, are reqired by HughesNet reps/engineers to view subscriber test results.  And no one said Comp IDs are HN assigned, nor was it even suggested.

 

The rest of your reply has absolutely nothing to do with what you quoted.


Ryzen 5 3400G | MSI B450M Pro-M2 MAX | 16GB Corsair Vengeance DDR4 3000 | XPG SX8200 Pro 512GB NVMe | Windows 10 Pro

Regarding the slow throughput (not bps speed), do these tracerouts shed any light?  Seems like a lot of time-outs.

Tracing route to hughesnet.com [34.197.164.140]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.42.1
2 612 ms 604 ms 579 ms host1743300193203.direcway.com [174.33.203.193]
3 607 ms 549 ms 592 ms host17433005205.direcway.com [174.33.205.5]
4 652 ms 648 ms 650 ms host17433004205.direcway.com [174.33.205.4]
5 619 ms 639 ms 619 ms 4.14.190.73
6 * * * Request timed out.
7 635 ms 670 ms 619 ms 4.15.44.98
8 685 ms 662 ms 699 ms 176.32.125.220
9 700 ms 655 ms 702 ms 176.32.125.231
10 * * * Request timed out.
11 680 ms 659 ms 739 ms 52.93.129.237
12 658 ms 655 ms 725 ms 54.240.229.187
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 684 ms 655 ms 705 ms 52.93.28.162
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 689 ms 719 ms 654 ms ec2-34-197-164-140.compute-1.amazonaws.com [34.197.164.140]

Trace complete.

----

Tracing route to qrz.com [23.23.229.197]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.42.1
2 617 ms 609 ms 589 ms host1743300193203.direcway.com [174.33.203.193]
3 578 ms 589 ms 609 ms host17433005205.direcway.com [174.33.205.5]
4 626 ms 607 ms 562 ms host17433004205.direcway.com [174.33.205.4]
5 621 ms 579 ms 665 ms 4.14.190.73
6 * * * Request timed out.
7 631 ms 648 ms 669 ms 4.16.116.254
8 668 ms 712 ms 705 ms 54.239.104.64
9 704 ms 679 ms 679 ms 54.239.104.75
10 * * * Request timed out.
11 646 ms 679 ms 709 ms 54.239.43.174
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 742 ms 729 ms 719 ms 52.93.28.196
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.

Trace complete.

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

Thanks,  Woody

 

 

Here are some ping results:


Pinging hughsnet.com [46.166.182.64] with 32 bytes of data:
Request timed out.
Request timed out.
Reply from 46.166.182.64: bytes=32 time=753ms TTL=57
Reply from 46.166.182.64: bytes=32 time=756ms TTL=57

Ping statistics for 46.166.182.64:
Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),
Approximate round trip times in milli-seconds:
Minimum = 753ms, Maximum = 756ms, Average = 754ms

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

Pinging qrz.com [23.23.229.197] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 23.23.229.197:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

 

 

GabeU
Distinguished Professor IV

@hamradio 

 

My traceroutes to qrz and HughesNet look very similar, as does the ping to qrz (100% failure).  My Hughes ping is fine, though.  

 

I went to qrz.com, and after five minutes of it trying to load and still only having a blank screen, I closed it and tried again, at which point it opened and finished loading in 18 seconds.  I'll try it again in a couple of hours to see what happens.


Ryzen 5 3400G | MSI B450M Pro-M2 MAX | 16GB Corsair Vengeance DDR4 3000 | XPG SX8200 Pro 512GB NVMe | Windows 10 Pro

Think you're seeing the poor handoff between your gateway provider, CenturyLink (4.14.190.73) through a bunch of Amazon servers. For example, why they're routing you via Amazon Ireland (176.32.125.220 and 176.32.125.231) to get to the HughesNet site is anyone's guess.

 

If I recall, we might be on the same gateway. For what it's worth, I get similar results.


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

Thanks for the reply.   The time outs appear to occur after directway.  Sounds like a HN problem in its routing...

I don't think there is anything I can do about routing issues.  No?, Yes? 

If no, then HN needs to "step-up" and fix the problem.

 

Woody - KZ4AK

 

HN likely has a direct link to their provider. It's CenturyLink that does the routing, not HN.


* 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 have had similar experiences.  Sometimes a "forever wait", sometimes an incomplete load from sites.   Then, a fresh try sometimes works.   
@GabeU wrote:

@hamradio 

 

My traceroutes to qrz and HughesNet look very similar, as does the ping to qrz (100% failure).  My Hughes ping is fine, though.  

 

I went to qrz.com, and after five minutes of it trying to load and still only having a blank screen, I closed it and tried again, at which point it opened and finished loading in 18 seconds.  I'll try it again in a couple of hours to see what happens.


 


Well Mark, that is interesting.  Too bad it is not something as a user of HN that I cannot do anything about that.   Sure do wish HN would address the problem.
Woody
@MarkJFine wrote:

HN likely has a direct link to their provider. It's CenturyLink that does the routing, not HN.


 

CenturyLink has to admit *they* have a problem first, and they haven't in over a year.


* 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

"It's not us; must be you" seems to be the go to answer from many providers of goods and services. 

 


@MarkJFine wrote:

CenturyLink has to admit *they* have a problem first, and they haven't in over a year.


 


@maratsade wrote:

"It's not us; must be you" seems to be the go to answer from many providers of goods and services. 


I'm still seeing 1-minute delays on things, and my twitterbot is still getting occasional OAuth timeouts to Twitter - both issues are outside of HughesNet, but involve sporadic delays in CenturyLink's backbone.

 

If I complain to CenturyLink, they won't talk to me because I don't have a user account.


* 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 imagine that if you did have an account they'd argue the problem is on your side.   I have to wonder if there have been complaints (from account holders) and CL is just saying "must be you, because it ain't us." 

 


@MarkJFine wrote:

If I complain to CenturyLink, they won't talk to me because I don't have a user account.


 

Exactly...  HN needs to become more agressive with CL since we, the victims, carry no weight with complaints to CL

Woody.