Hughesnet Community

Has HughesNet figured out a way to fake a speedtest?

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

Has HughesNet figured out a way to fake a speedtest?

I'm sitting at home right now, and my speedtest says I'm getting 42mbps, which is pretty fast for HughesNet. But we can't get any show to load on Netflix, nor even most of the thumbnail pictures of shows. The internet on my computer is slow as molasses as well. It seems we get spurts of good service, but then back to garbage. I've been a customer for a week and am strongly considering cancelling. A rep was already out and replaced our radio and modem. I switched off my video data saver and it helped a bit, but we still only get spurts of decent internet. And before you say it, weather isn't the issue. It slows down in bad weather, but I expect that, however it does this garbage when its clear and sunny. I really don't want to sit through hours of arguing with the Indian guys in Support trying to get someone to come out. Can someone bypass them and just get me help? No disrespect to the Indian guys, just tired of sitting on hold for hours, having them act like I'm stupid, and then getting hung up on and having to call back. Verizon's data service pulls, at best, 5mbps, and I can switch my phone to Verizon data and get better service. I may just consider getting a hotspot, but HughesNet should be pulling much faster internet. HELP!!!

21 REPLIES 21
maratsade
Distinguished Professor IV

It's congestion, and the deprioritization of streaming. 

Then why is my laptop running so slow as well? I can certainly see where they are throttling my streaming but my internet is bogged way down too, but my speedtest still says 42mbps.
maratsade
Distinguished Professor IV

Because of congestion.  It's not just affecting streaming, though it's particularly noticeable with streaming. 

GabeU
Distinguished Professor IV

@dannymac86 

 

In addition to what maratsade said about congestion and prioritization, the infrastructure, as well as the servers your system is communicating with, are being overloaded as well.  Many of those things don't react well to congestion, as well as the higher latency inherent to satellite internet.  

 

Also, if your beam and/or gateway are already heavily loaded, what's going on now is only going to make it that much worse.  As well, the extent of the effects of what's going on can vary from location to location, as individual beam and or gateway load varies by location.

 

That streaming is not working very well and that web pages are taking a longer time to open is the new norm, or at least until things start calming down and people start going back to work, which could be quite some time from now.  As well, just in the week leading up to 3/20 the system load had doubled.  It's likely doubled again since then, so a fourfold or more increase in traffic over the norm, and on a system which already has a relatively small amount of bandwidth.  Normally that bandwidth is enough, but not now.  And, unlike ground based services, they can't easily add more.  The only way to do so is with a new satellite, and that's not going to happen until next year.

 

Lastly, for an individual comparison, my overall speeds can reach as high as yours, yet trying to watch a Youtube video is challenging, even in 144p.  Prior to the pandemic, I had no problem watching them in 1080p, though I usually kept it at 480p to save data.

Their "prioritization" should probably reduce the traffic for speed tests, but it obviously doesn't.  So, while they aren't faking the test, the results not indicative of the speeds you will see, because nearly everything else is slower by factor of 10 or more.

C0RR0SIVE
Associate Professor

It is highly possible that the route between your computer, and the speedtest server you are selecting has minimal congestion, where as the route between you and lets say, Netflix (or any basic website) could have a point of extreme congestion.  This has been a common theme lately with so many online.

That's technically true, though Netflix is sort of the gold standard for redundancy and scale, so it's hard to imagine that being the case for very long with the automation and adaptability that their ecosystem has (See the Netflix Open Source Software project for reference https://netflix.github.io/).  My experience shows that this speed difference is consistent no matter which site/server I'm communicating with so, so if it really was upstream of HughesNet, it would likely be affecting enough users and ISPs as to have generated some significant headlines.

 

Either way, some simple sluething with traceroute would probably prove it one way or the other.  I'm not on HughesNet for the next week or so, but I can always check when I'm back on.

GabeU
Distinguished Professor IV


@Michael57 wrote:

Their "prioritization" should probably reduce the traffic for speed tests, but it obviously doesn't.   


No, it shouldn't.  Activities give a signature, and that signature is how something is identified for prioritization.  Speed testing wouldn't be one of the activities that's hindered.  It's primarily streaming, game downloads and certain other types of file downloads. 

Actually, that's not true at all.  There's nothing particularly special about speed tests, they are either streaming some data or doing a file download, like pretty much everything else on the internet.  They aren't their own class that would ever receive special treatment at a "signature" level.  A speedtest is, however, easily identifiable by URL, and so it's easy to whitelist.

Actually, I take that back a little bit.  Given the way HughesNet asks folks to do a specific speed test for getting escalated service for perceived performance, that is a good reason to not throttle it.  That way, they can tell if the customer's local hardware is the problem, but it also means that at least that particular speed test will never be a good indication of speeds customers should expect for normal traffic.

 

Now, why they also seem to white list other speed tests...I don't really have an answer for that.

GabeU
Distinguished Professor IV


@Michael57 wrote:

Actually, that's not true at all.   


Actually, yes it is.  And I didn't say there was anything special about speed tests.  Certain activities that are prioritized or deprioritized are identified by the signature they give.  Speed tests aren't one of them.  Speed tests are not streaming/video, nor game downloads, nor torrent downloads, etc.

 

Not everything is being prioritized or deprioritized.  In fact, most things aren't.  It's primarily work/schooling and those acivities that use large amounts of data, respectively, and some of those things can be identified by their signatures.    

 

And there's no doubt some things are being whitelisted, and that's part of the prioritization.  Zoom is one of them, or at least logic would dictate that it is.

No it isn't.  A game download and a file download are EXACTLY the same thing, games are just files.  There is no signature that will differentiate them.  Unless by signature you just mean the URL (which is a weird usage of the term)?

 

HughesNet (I would hope) is not trying to do packet inspection of all downloads to attempt to determine what the file is, in order to prioritize say a Document over a Game...that would be insantity.  The inspection is worth it to determine the type of traffic it is, at which point a speed test is just as ordinary as a game download, where as a VOIP packet (like zoom uses) could be given a higher priority.

 

That said, if you are trying to conserve bandwidth and minimize congestion, speed tests absolutely should be de-prioritized.  They are realatively big downloads, when compared to most web pages and completely superfluous.  The noted exception for debugging excluded.

 

 

A packet is a packet. It contains data, routing information, and possibly security and crc checks. The only major difference between packets are their inherent size.

 

The protocol that involves those packets is a different story: What's getting lost in this conversation is the fact that some speed tests use simple protocols similar to file downloads, others use streaming techniques which are vastly more complicated and not suitable for satellite internet.

 

What's also getting lost in this conversation is the incorrect assumption that something like TestMy is being used as an accurate measurement of speed. It's being used as a 'common' measurement of speed in order to remove several other variables such as protocol, routing (to an extent), etc.


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


@MarkJFine wrote:

A packet is a packet. It contains data, routing information, and possibly security and crc checks. The only major difference between packets are their inherent size.

 

The protocol that involves those packets is a different story: What's getting lost in this conversation is the fact that some speed tests use simple protocols similar to file downloads, others use streaming techniques which are vastly more complicated and not suitable for satellite internet.

 

What's also getting lost in this conversation is the incorrect assumption that something like TestMy is being used as an accurate measurement of speed. It's being used as a 'common' measurement of speed in order to remove several other variables such as protocol, routing (to an extent), etc.


The payloads of the packets of course are very different and modern networks can inspect them.   Typically that is done for malware but can also do some level of prioritization on them, like for VOIP traffic (Cisco made a killing off of this in the 90s).  But for all intents and purposes of this thread, you are correct.  

 

I think that last paragraph is the contentious piece though, and the question behind the question for this thread. 

 

After having read through a few threads of folks concerned about their network speed and inability to do certain things, a fast speed test seems to be used as a way sort of absolve HughesNet.  That is then followed up with comments that seem to suggest that either the website/service the customer is using or the route to get there is the problem.  That last part doesn't pass the sniff test. 


@Michael57 wrote:

That last part doesn't pass the sniff test. 


Ok. Maybe this will further explain it. Each user is assigned a spot beam on the satellite that covers their specific geographic location. Several beams (up to 8 or 9) are then routed to one of 19 different ground stations spread across the West Coast. Each of those legs have different load demands. Each are also serviced by potentially different internet providers (however most - Level3, Qwest, etc. - have been merged under CenturyLink's various acquisitions), and therefore different nationwide backbones.

 

So, someone using the ground station in San Diego,CA may or may not have a more efficient route than someone using the Billings, MT ground station due to overall distance (and hence latency and how that's handled), weather, and most importantly the competency of the internet provider.

 

Tried to excise my negative CenturyLink bias, but that's not happening. But I think you can start to see how complex this really is. It's not as straightforward as terrestrial, where a lot of these parameters are neglegable.


* 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


@Michael57 wrote:

After having read through a few threads of folks concerned about their network speed and inability to do certain things, a fast speed test seems to be used as a way sort of absolve HughesNet.  That is then followed up with comments that seem to suggest that either the website/service the customer is using or the route to get there is the problem.  That last part doesn't pass the sniff test. 


A speed test, whether run prior to posting or by instruction, is simply a troubleshooting tool in order to determine whether an issue is as a result of overall slow speed or something else.  Basically, it's step one in the troubleshooting process, or step two after first determining whether someone is in FAP.

 

Sometimes a problem IS due to issues along the route.  Other times it's not.  It's not a go to excuse, but is only suggested when it could be the actual cause, and very often when a problem along the route is suspected, further steps are taken to see if that truly is the cause.  This isn't always the case, though, as sometimes the cause of the issue is already known.

 

Edit:  That's not to suggest slow speed can cause all problems seen, of course.

First, @MarkJFine  thanks for contributing. @GabeU replied before I could reply to your comment so I'll just speak to both here for simplicity.

 

I'm a longtime software engineer, I don't code much anymore, but I'm still deeply involved at a leadership level.  At one point, I worked for an online brokerage.  Milliseconds costs tons of money in that scenario (not for us really, but for the customers) and so if you want customers, you have to have crazy optimizations around the time to from login to placing a trade, it matters greatly. 

Today, I work for a company that has a massive website presence, one of the largest (in terms of traffic) in the world.  I'm sure you've all been on one of the thousands of sites that we run at some point.  Again, we spend thousands of hours optimizing our traffic and load times, honestly it's still something we are measured on relative to our competition, frankly I think it's nonsense for our vertical but that's a whole other conversation.  I point this out, not to suggest that I know more than you on this topic, but simply to short circuit some explanations.  I know the factors involved for both terrestial and satelite internet.  I also understand, deeply, the nuance involved that affects "how fast a page loads" or stream quality etc. from source to destination and back, and what things are whose responsibility in the chain.

 

Here's my concern with that response ("that the problem is with the service or the route") It's a handwavy response that's a bit unfair and it's probably wrong.  The average person will not be able to refute it, and it's always a possiblity that an upstream issue is in fact the cause.  It's nearly impossible to rule out, especially if you don't have another ISP to use at that moment, and if you are using satelite you likely don't at that point in time.  It's like saying that you think you have a brain tumor, because you have a bad headache.  You could... but probably, it's not a tumor ( 😄 ).

 

I also understand that managing throttlling and QoS during a time of massive usage isn't easy either, and satelite internet has a hard cap that just can't be scaled out, which adds to the challenge.  That said, the HughesNet network is the primary influencer of the speed customers are seeing. Whether that's HughesNet network congestion, well tuned prioritization, poorly tuned prioritization or some combination of all of it.

Like you, I was once very technical, but found myself in upper management, now finally doing technical things again in early retirement. My point in all that is I understand your skepticism.

 

However, I could bore you with the proof I have of the problems upstream with CenturyLink. Common things that I've seen on HughesNet that were replicated on servers I have outside of HughesNet, but also behind CenturyLink. Stupid things like simple misrouted paths. Things like 1 minute gaps in service that send latency through the roof. Things like twitter bots and automated backups that end up timing out on authorization at their destinations (some of which are only two hops away... I actually had to move the twitter bot to a server on 1&1 in Germany for it to finally work).

 

I'm usually skeptical of most things. I'm not a skeptic on this.


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

Hey! I'm still very technical, jeez don't put me out to pasture yet! 😄 

 

Oh, I don't doubt that XXX provider has suboptimal configs and even sometimes messes things up enough to cause an acute situation. Though even then, there's still a conversation to be had there about responsiblities and SLAs's but that's a topic for a different day.  In any event, it's still the exception, and in this case, it still doesn't pass th sniff test.

 

The only sites that work at even a 10th of the advertised speeds (of the literally hundreds I've tried in the last month) are speed test sites, and they operate above advertised speeds every single time.  That's just way too specific...

 

The problems with CenturyLink have been going on for well over a year, possibly two. I picked SDO because they are one of the ones served by them. They won't admit there's a problem, and won't even talk to me unless I have a customer number, which clearly I don't. It's that bad. You may remember they were the ones who brought down the internet on the west coast for a few days over one summer because of a simple card failure. It even made network news.


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