Hughesnet Community

CenturyLink data clog

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

CenturyLink data clog

I sent my report to HughesNet regarding the huge latency spikes (and, as I said, I named names, both those employees who were helpful as well as those who were not helpful).

 

(As an aside, they did find a problem, which they are going to work on.)

 

During our recent phone conversation, they were interested in this data clog by CenturyLink.  I referred them to the forum here where it is talked about, and HughesNet said they were going to send someone to research it.

 

I thought it would be good to have a new thread where people can list the observations/experiences so maybe HughesNet could located and identify the specific problem with CenturyLink.

 

HughesNet said if there is indeed a data clog by CenturyLink, it would be a major fix.  So any data we can give them I think would be very helpful.

4 REPLIES 4
MarkJFine
Professor

Hey... if someone can do something with this, have at it (and you'll also have a friend for life):

 

1. The problem is best characterized by a 1-minute (minimum) gap where nothing happens, forcing some applications to time out.

 

2. In some cases it manifests itself after an inital burst of transfer activity, then just goes silent for a minute, and usually (but not always) picks back up again. Other times it occurs right at the start and you might not see it happen for the rest of a file transfer.

 

3. There is no regular pattern to accurately predict when these will happen (time of day, etc.), and it does not happen all the time, however I have a theory that they *might* coincide with some of the massive php vulnerability scripts being run by Chinese hackers [note: that mess is another story, if anyone's interested].

 

4. It's not specifically limited to HughesNet where CenturyLink (ex-Level3, ex-Qwest) is the gateway's provider. I have a prime example where I have an application on a server I administer on pair.com that remotely posts to Twitter 3 times a day. At least one of these per day will fail due to an oauth timeout, caused by CenturyLink - where they are the only 4 hops between servers). See below:
 Screen Shot 2019-12-13 at 3.22.42 PM.jpg

Incidentally, this is how I initially knew CenturyLink was the cause of the dropout problems being exhibited on some of the HughesNet gateways. There are other examples that explicitly single CenturyLink out, but this is the best one.

 

5. I have personally contacted CenturyLink about this problem twice, but both times they didn't understand that this was a backbone problem, and then refused to even talk to me without a CL account number.


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

Hey... if someone can do something with this, have at it (and you'll also have a friend for life):

 

This is going to take HughesNet rerouting traffic around the bad servers.  CenturyLink certainly has no incentive to fix the problem as long as their own customers aren't complaining.  (And I hear they are complaining)

 

When I was running traceroutes, I would always see a timeout from a CenturyLink server.  Either a quest or Level13 like you have in your image.

 

If rerouting is to take place, HughesNet says this is a major, major issue, so it is going to take a lot of feedback to convince them to do this.  So anyone who is being affected by this really should be speaking up and providing the data.

 

They ARE looking into this.  At least, that is what they told me.  Well, the higher-up told me.

 

And as you, completely random but extremely often, like every second.

Usually get a timeout on the same hops, but that could be that they're rejecting ICMP. What's interesting is the real long one (.7s+) in-between that I 'caught'. If that doesn't illustrate the 1-minute gap occurring in the backbone I don't know what does.

 

Edit: Keep in mind that this traceroute was done completely outside of HughesNet, between pair.com and twitter.com - all terrestrial internet, not satellite, where a 700mS ping would not be normal.


* 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'm with you Mark, et.al. This same problem persists for me. I have yet another support phone call return scheduled for the 19th or before (well , *maybe* "engineering" will call). However, my expectations that this issue will be resolved are low. BTW, HN responded to my complaint to the Fed Com Comm. with a very disingenuous letter. It mostly covered what is not the problem, like weather, bad wifi connection (I'm Ethernet), etc. Pretty much the same script that comes from phone support. They ignored the "actual throughput" issue. The commission suggested I take up the issues with the ISP. Sadly that is a Ha! Ha! Woody