Forum Discussion
Failing To Provide Service
I rebooted the HT2000W shortly after 8pm 9/2 Eastern time (0000 UT 9/3) and that is when I started to have the issue, so I am not sure if my reboot of the HT2000W was the start for me, or if it was at 0000 UT (8pm EST/6pm MT).
maratsade, did a reboot start the issue for you, or are you on mountain time?
I use a batch file to automate grabbing the logs from the HT2000W after it creates them at 0000 UT/8pm Eastern. I then use a spreadsheet graph to look at usage for each device and other numbers from the log, so I can see the SQF bounce all over and lose connection at the gateway after 8pm 9/2.
Ignore the 50+ Mbps numbers, they are caused when I reboot the HT2000W and the usage accumulators reset back to zero -- the spreadsheet here is treating it as a rollover of 32 bit integers, so in the graph it just creates the illusion of a data usage spike. This is because I rebooted, and stitched the logs together and is not related to the issue.
The dark blue line in the graph for SQF has gone crazy since 8pm 9/2 and when it gets too low connection is lost.
Hope this is resolved soon, but I was wondering if others can avoid it by not reseting/rebooting the HT2000W until the fix is in?
MrBuster, I'm on Eastern time, and I realized the system was down in the evening, so I don't know exactly when it first went down. I checked the modem and about 3 lights were out. I rebooted the modem, and all the lights except System came back on. This morning (9/3) at around 6:30 am, System was still out. I rebooted the modem again, and also restarted the computer, and it was working. It's still a bit glitchy, though. Sometimes the connection cuts out, then it comes back. So, for me, the second reboot ended the issue. The first reboot did not.
- MrBuster7 years agoSenior
Thanks -- since you are eastern time and you first noticed the issue 6:30pm last night (9/2), it is apparent that we started to experiance the issue at different times. The issue did not start for me until I rebooted shortly after 8pm eastern time. From the graphs you can see my performance was excellent before 8pm (except for a short heavy rain at 5pm).
The issue causes intermitent connections because the satellite signal strength is all over the place -- so everything is working then when the SQF drifts too low there is a loss of connection for a few seconds while reassociating to the gateway.
Under the System Status screen, the 'Satellite Receive Signal Strength' value is the SQF in the log -- do you see your value jumping all over the place, or has it settled down to a constant value for you?
Thanks!
- maryd17 years agoNew Member
My connection(s) are still all over the place! Obviously, not all affected customers have been restored. I've re-booted numerous times and still can not maintain a connection. I'm in Ohio with sunny blue skies and more than frustrated with Hughes Net performance
- maratsade7 years agoDistinguished Professor IV
They may still be fixing the issue. It doesn't seem to be a weather related issue, so the weather in Ohio would not impact performance in this case. Things break, be patient. Hughesnet is working to restore full performance.
My connection(s) are still all over the place! Obviously, not all affected customers have been restored. I've re-booted numerous times and still can not maintain a connection. I'm in Ohio with sunny blue skies and more than frustrated with Hughes Net performance
- maratsade7 years agoDistinguished Professor IV
It varies, and it's affecting performance, but most things can be done just fine at the moment. Streaming isn't working so well because the system cuts out for nanoseconds and the streaming service doesn't seem to like that.
MrBuster wrote:Under the System Status screen, the 'Satellite Receive Signal Strength' value is the SQF in the log -- do you see your value jumping all over the place, or has it settled down to a constant value for you?
Thanks!
- C0RR0SIVE7 years agoAssociate Professor
Decided to check some logs on my server...
Looks kinda nasty. - MrBuster7 years agoSenior
Is it my imagination or is there a correspondence with the graphs? We are on different beams and different gateways...any thoughts? The scale is a little different, but the drop offs seem to hit about the same time....
- C0RR0SIVE7 years agoAssociate Professor
Hrm... Not sure...
I am on SDO 066.... I know Mark is on SDO068 (i think~!), not sure about everyone else.
I do know this, packet loss and website load times are increasing at at an alarming rate... - MarkJFine7 years agoProfessor
Assuming the graph is showing ET, I can vouch for the mess at ~12:42. Am on beam 68, but I think that may be irrelevant since it appears to be system-wide.
That said, the SQF may be relative. For example, my usual level is around 104-110, which is generally pretty good. Any full outages I see might be less frequent than someone who has a lower usual SQF because it's easier for them to hit the lower threshhold.
However, I seem to be on a different IPGW ID than I was at 12:42 (either that or my memory is failing me), which means that although a prolonged outage might not have affected me, something was severe enough to trigger re-association with the gateway. It was likely quick enough that I didn't even notice.
- MrBuster7 years agoSenior
Yes, these times are ET, but I was surprised to see any correspondence in the graphs since we are different beams and gateways.
For me SQF is never above 95, but with this issue, it has jumped up above 100 at times but it jumps all over. Even though my SQF is always lower, my performance is really good -- often above 40 Mbps even in "prime time" and I rarely have any drop off with my IPGW ID sometimes going 2 weeks before it changes. Before this issue, it dropped at 5pm because of a very heavy rain -- I usually maintain connection unless is a very heavy downpour.
The unstable SQF is causing a drop off/change of IPGW ID every 30-50 minutes it seems. Mine just changed again at 3:30pm.
- MarkJFine7 years agoProfessor
Yeah, unless the SQF doesn't go below 70 or so you're not going to see much degradation in overall speed between yourself and the gateway. For the majority, SQFs above that level are acceptable bit error rates, not requiring packet resends. what affects speed at that point is usually the congestion from others pounding the servers at the gateway, thus causing delays. Well, either that or my favorite bugaboo: the upstream provider (Level3), which in my case tends to drive me insane at times by invariably throttling routes to Microsoft and others seemingly at will.
- skybox7 years agoSophomore
Watch how fast service returns tommorow when everyone comes back to work. Hugesnet you can't close down the shop over a holiday!
- MarkJFine7 years agoProfessor
skybox wrote:Watch how fast service returns tommorow when everyone comes back to work. Hugesnet you can't close down the shop over a holiday!
They didn't close up shop. Think you owe the people who have been up all night and all day today (one of them an admin here) an apology, while you had a nice, easy day off, grilling steaks and burgers.
- deanwferguson7 years agoSophomoreActually the level4 techs got the day off. If you called customer service today you would know. Don't attack people frustrated understandably. Some of us have never received the service we pay for yet are at the mercy of the two almighty satellite providers
- maratsade7 years agoDistinguished Professor IV
Hear hear. Well said, Mark.
. Think you owe the people who have been up all night and all day today (one of them an admin here) an apology, while you had a nice, easy day off, grilling steaks and burgers. - maratsade7 years agoDistinguished Professor IV
Some of you also don’t see how hard these people work to improve the service you’re always dissing.
Some of us have never received the service we pay for yet are at the mercy of the two almighty satellite providers
Related Content
- 5 years ago
- 4 years ago
- 3 years ago
- 5 years ago