Hughesnet Community

HughesNet Tier 4 support refused to help with unusual high latency problem

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

HughesNet Tier 4 support refused to help with unusual high latency problem

Here is a record of this current problem.

 

Record begins.

 

Case ##124526040

Had issue with low speeds in evening.  400K speeds.  Was switched to different satellite.  Speed problem solved, however, now am experiencing very high and wildly swinging ping times.  Between 800 ms and 44,000ms!!!!!!!!!!!!  (That 44,000 was only recorded once.  Usual upper limit is 5,000 ms)

 

At times, websites like Facebook won't load and any kind of streaming is impossibly stuttered.

 

Called Tier 1 support.

 

First call.  Weather was blamed.

 

Second call same day.  Weather was blamed.

 

Third call next day (Next day (10-18-19).  Disconnected

 

Called back.  Represetative clearly did not speak English natively and had some communication problems.  Representative said case has been escalated to Engineering department and that I would receive a call tomorrow in the AM. Reference #124564944.  Very oddly the representative asked me what I had for dinner.


Engineering called back 10-21 in the afternoon. Heavy storm overhead. Have to call back.


Called back 10-22 1:37 PM. Told Tier 4 Representative about ping problems.  I told him that ping was wildly swinging between 800ms and a record 44,000 ms.  I also said that I never had this problem on the old satellite.

 

Representative said he would not do anything about it, said 2000+ latency is just the way that it is. (Not a direct quote)

 

I acknowledged that he refused to do anything about it.  Representative thanked me for calling HugesNet Support.

 

End of record.

 

So bascially HughesNet Tier 4 told me to go suck an egg.  They won't do anything about it.

 

Great customer service.

 

Wish there was another company in my area.  Will keep looking and hoping.

79 REPLIES 79


@maratsade wrote:

It wasn't me asking the question, @MarkJFine .  I was quoting Lighthope. 🙂

Edit: but it does appear that CL is right messed up. 


If I had to bet money, I'd say it was CenturyLink that was the actual problem.  The issue we have here is that HughesNet won't even acknowledge there is a problem, and then spout off brain-dead statements like "That is how satellite tech works" and "You can go find another ISP."


@maratsade wrote:

 

Thank you, Lighthope.  Earlier on in the thread, you had posted that "I also tried the command prompt ping test. That comes out at 600ms fairly consistently. So now we have to ask the question: Why does a ping test come with low ping, but streaming data have such problems."

 

Are there specific pages (like the ones you had linked to upthread) that have issues loading, or does everything load slowly or fail to load?

 

ETA: you don't have to respond if you don't want to.  I'm just curious, as a subscriber, about the experiences of fellow subscribers. 

 

Various pages load slow.  It is inconsistent.  Facebook, however, is one of the worst, likely because it hooks into so many other things.


 

maratsade
Distinguished Professor IV

I remember that @GabeU had issues with Facebook as well.  

 


@lighthope1 wrote:
 It is inconsistent.  Facebook, however, is one of the worst, likely because it hooks into so many other things.

 


 

GabeU
Distinguished Professor IV

@lighthope1 

 

If you're still subject to the two year agreement, have they offered to allow you to cancel without penalty?


@GabeU wrote:

@lighthope1 

 

If you're still subject to the two year agreement, have they offered to allow you to cancel without penalty?


I am not subject to it; I've long past it.

 

Sadly, there is no other internet service in the area.  I can't hit Viasat's satellite because of trees and there is no cell service in the area.

 

Belive me, if there was any other option, HughesNet would be far in my rearview mirror.

The point is that bad service should not just be "accepted".  We shouldn't learn to live with things that can be addressed but aren't because they know they are a monopoly, because someone is bad at their job, or if someone outright lies about something so as to not take responsibility.

 

I'm not talking about people who don't understand satellite.  I see a lot of posts from people who burn through their data either from downloading huge movies or because they have devices that suck up data.  I'm not talking about people who don't understand latency and the fact that the satellite is 20K+ miles out there and it takes time for a signal to travel.

 

What I am talking about is bad data management, bad trafficing, and other issues that are real and either are in the pervue of HughesNet or shoud at least be acknowledged.  I posted very recently about the trouble CenturyLink is giving HughesNet.  Even others have posted about it.  But as we have seen, HughesNet won't even acknowledge that.  Talk about head-in-the-sand!

 

When HughesNet or anyone has a problem, ignoring it doesn't make it go away.  And accepting it doesn't make it better.

 

We should never become someone who accepts poor service.  That just encourages more poor service.

For over2 months when I log in I do not get myhughesnet. It comes up every time as myaccount. I can accomplish nothing from there. I have called..texted....live chatted. I've been assured it would be corrected. Nothing haas changed. I am more than angry. Will contact AT&T to change providers. I have had Hughes over 9 years
GabeU
Distinguished Professor IV

@WLP36 

 

Your issue has absolutely nothing to do with lighhope's.  Please start a new topic in Tech Support, which you can do here.  

 

It may also help to post links so it's a little more clear as to what's going on.  Signing into where?  What site does it end up on?  Those links.

GabeU
Distinguished Professor IV


@MarkJFine wrote: 

If you look back a couple of years, (prior to the Level3 buyout) CenturyLink's *backbone crashed* for a week leaving the entire internet in a mess on the West Coast. It was heavily covered on the news. .


That CL outage from late last year (Dec 27, 2018) was awful as well.  Nearly two days.  😞  

maratsade
Distinguished Professor IV

I believe it was 37 hours, and it's what prompted the govt agency to pipe up, because of people's inability to reach 911. 

 


@GabeU wrote:
MarkJFine wrote: 

If you look back a couple of years, (prior to the Level3 buyout) CenturyLink's *backbone crashed* for a week leaving the entire internet in a mess on the West Coast. It was heavily covered on the news. .


That CL outage from late last year (Dec 27, 2018) was awful as well.  Nearly two days.  😞  


 


@GabeU wrote:

The result the TMN test gave me, using the Dallas server, was 2471ms, which is WAY off.  I don't know exactly how it tests, but I also tried a few other servers, with each one giving me results that I know are not correct.


This may exlain why TMN is giving you such high scores.

 

TestMy.net TCP Ping Tool

a.k.a. TestMy Latency is not the average ICMP ping you get from your command line. TestMy Latency is a totally different type of Internet Speed Test than what you may be used to. TestMy Latency runs on the Transmission Control Protocol (TCP) (layer 4 - transport) where as normal ping runs on ICMP (layer 3 - network). ICMP is not used to exchange data between systems and has no way of interacting or detecting issues with the layers above it (layers 4 through 7). It simply can't give a full picture of what's happening on layer 4. TestMy Latency is different and tests at the transport layer.

 

(Emphasis added)

 

So basically a command line ping which HughesNet says is most accurate, according to this, is most useless. And that TMN give a better "real world" look at the actual latency.

 

Or so they say.

GabeU
Distinguished Professor IV


@lighthope1 wrote:

So basically a command line ping which HughesNet says is most accurate, according to this, is most useless. And that TMN give a better "real world" look at the actual latency.


Actually, it's not, but there is no point in arguing with you if you're convinced.  

 

I can tell you, though, that relying on TMN's latency results aren't going to get you anywhere with HughesNet's reps or engineers concerning such.  


@GabeU wrote:

@lighthope1 wrote:

So basically a command line ping which HughesNet says is most accurate, according to this, is most useless. And that TMN give a better "real world" look at the actual latency.


Actually, it's not, but there is no point in arguing with you if you're convinced.  

 

I can tell you, though, that relying on TMN's latency results aren't going to get you anywhere with HughesNet's reps or engineers concerning such.  


I'm just quoting people who know about this stuff.  I've provided enough information to show there is a problem.  If HughesNet wants to put their head in the sand and say there isn't a problem, that's on them.

Think you're confusing using TestMy for speed vs using it latency.

 

Using it for speed has been the way to go in the past because it more or less normalized where the speed tests were going. For whatever reason their results haven't been as reliable as they have been, showing a lot of capture, hold, and release type corruption of the speeds.

 

Using it for latency (partially for the same reason) is not a good idea, because it will only show the overall latency of a path to them and not really pinpoint the precise location of the problem. That's why a locally run traceroute is best, because it can isolate problems with the route table, the gateway's provider, the server your're trying to reach, or any point 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.


@MarkJFine wrote:

Think you're confusing using TestMy for speed vs using it latency.

 

Using it for speed has been the way to go in the past because it more or less normalized where the speed tests were going. For whatever reason their results haven't been as reliable as they have been, showing a lot of capture, hold, and release type corruption of the speeds.

 

Using it for latency (partially for the same reason) is not a good idea, because it will only show the overall latency of a path to them and not really pinpoint the precise location of the problem. That's why a locally run traceroute is best, because it can isolate problems with the route table, the gateway's provider, the server your're trying to reach, or any point in between.


I wasn't using it to find where the problem was, only to show that there was a problem.  Right now, HughesNet won't even acknowledge that there is a problem, because why admit when you can deny?  (Seems to be HughesNet's go-to-solution)

 

Finding where the problem is is far beyond my ability.


@lighthope1 wrote:

Finding where the problem is is far beyond my ability.


But using a sample path to only one place and calling it a problem everywhere without proof isn't going to be taken seriously.


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

@lighthope1 wrote:

Finding where the problem is is far beyond my ability.


But using a sample path to only one place and calling it a problem everywhere without proof isn't going to be taken seriously.


I provided several examples of prolems.  If HughesNet ignores that, that is a them problem, not a me problem.