Search:  

 
 
   All ForumsHot TopicsGallery






how-to block ads


 
Forums » Satellite Connectivity » HughesNet Satellite » Deliberate Limited Bandwidth 4pm to 12am ET
Search Topic:
Share Topic:
RSS topic:
toggle:
flat / full
normal / watch
Posting:
Post a:
Post a:
[DW4000] ping to DNS IPs fails - help plese! »
« [DW4000] DW4000 gateway/transponder changes?  
AuthorAll Replies


selling hughes

@direcpc.com

reply to CarlsDad
Re: Deliberate Limited Bandwidth 4pm to 12am ET

said by CarlsDad See Profile :

I am receiving several phone calls a day from HughesNet customers complaining about slow speeds and basic unusable performance. The customers are spread across several satellites and include both 6000 and 7000 users. They all get good performance early in the morning and very late at night, but during normal peak hours their speeds drop to 100 to 200 and ping times jump to 1500 to 2000 ms. This effectively kills server connections and any thing but basic HTML pages will not load.

I am guessing Hughes has over loaded their NOC capacity and is not going to increase capacity due to the new Spaceway system coming online. Hopefully enough currant users (mostly older 6000 with no contract) will switch to the new system thus relaxing congestion on the currant network.

Until then I am pulling all plugs on any satellite Internet sales.

When network congestion gets bad enough, you can have speed test jumping from 50 to 900 back to back. It is not a matter of time, just a simple matter overall usage. One second there may be little traffic, but 2 seconds later more people are getting their email.

I bet during American Idol tonight, performance will be better than last night, which had little NEW programming. I also wonder how the writers strike might have affected this issue. With virtually no new programming, maybe more people are using the Internet to view alternate formats of TV programming, entertainment or streaming music. Something to think about!
I applaud your integrity and judgment for suspending sales of Hughes systems until/unless some of these issues are worked out. While it is understandable that Hughes would suspend adding additional capacity to existing satellites in anticipation of being able to use Spaceway III to handle a good part of its bandwidth needs, the thing that shows lack of integrity on their part is that they have continued to take on new customers without the capacity to meet their bandwidth needs. Instead, the right thing to do would have been to temporarily suspend adding new accounts until Spaceway was up and running.

Also, for those trying to understand the flow control and bandwidth allocation percentage, I've been monitoring my bandwidth allocation percentage. I've seen it vary from as little as 9% to as much as 60%. In both cases, though, my system was still getting plan maximum speeds (I'm one of the fortunate ones who is not on an overcrowded gateway). So, I'm not really sure what the significance of the bandwidth allocation percentage is. On the other hand, I'm confident that, when flow control is enabled, that it is done at times when demand for bandwidth is the heaviest. I now that, at the NOC, Hughes has print outs for each transponder on each satellite, and those print outs show when, on that transponder, bandwidth demand is typically above the level of available bandwidth, and I'm confident that it is, at those times, when the flow control is enabled. The times, however, when it is enabled, may well be different from one transponder and satellite to another, depending on how heavily that transponder is overloaded. The idea of the flow control is ensure that everyone can get some bandwidth, even if at much slower speeds. Without it, some would be getting higher speeds, but others would not even be able to connect.

sovtman

join:2007-04-20
Marlboro, VT

said by selling hughes :

Also, for those trying to understand the flow control and bandwidth allocation percentage, I've been monitoring my bandwidth allocation percentage. I've seen it vary from as little as 9% to as much as 60%. In both cases, though, my system was still getting plan maximum speeds (I'm one of the fortunate ones who is not on an overcrowded gateway). So, I'm not really sure what the significance of the bandwidth allocation percentage is.
I can't figure out BW allocation either. And your observations as not correlated to speed confirms my confusion.

My point is simple, yes network congestion can cause bw degradation, but it defies simple logic (and common sense) to think that the consistent, dramatic drop in my service at 4PM ET everyday is merely a fact of network congestion. Something in the system (whether intentionally or through a screw-up) is throttling down my bandwidth at the same time everyday. Either HN is anticipating congestion or they messed something up.


selling hughes

@direcpc.com

said by sovtman See Profile :

said by selling hughes :

Also, for those trying to understand the flow control and bandwidth allocation percentage, I've been monitoring my bandwidth allocation percentage. I've seen it vary from as little as 9% to as much as 60%. In both cases, though, my system was still getting plan maximum speeds (I'm one of the fortunate ones who is not on an overcrowded gateway). So, I'm not really sure what the significance of the bandwidth allocation percentage is.
I can't figure out BW allocation either. And your observations as not correlated to speed confirms my confusion.

My point is simple, yes network congestion can cause bw degradation, but it defies simple logic (and common sense) to think that the consistent, dramatic drop in my service at 4PM ET everyday is merely a fact of network congestion. Something in the system (whether intentionally or through a screw-up) is throttling down my bandwidth at the same time everyday. Either HN is anticipating congestion or they messed something up.
Actually, I think the use of flow control does have a logic to it (even though it may be a logic without ethics). Hughes knows, statistically, how much bandwidth demand there is likely to be during each hour of the day on any given transponder. What they are doing, then, is preemptively applying the flow control during those hours when they know that demand is likely to exceed available bandwidth. That means that, during that time, there may be times when the level of demand would allow speeds above the throttled level, but, unfortunately speeds will still be capped at the lower level. It also means, though, that, at other times, everyone will be able to get on line in spite of high bandwidth demand. Clearly, if Hughes was not badly overselling bandwidth, the amount of time when the flow control was enabled would be small. But, the more customers are crammed into a transponder, the more hours during the day when the flow control will be enabled.

With regard to the BW allocation %, I'm not even sure whether it is good to have a high number or a low number because I don't know whether the number shows how much bandwidth I have available for my use or whether it shows how much of my available bandwidth I've used. Without further clarification from someone with knowledge, I can't draw any conclusions about that stat.

sovtman

join:2007-04-20
Marlboro, VT


edit:
February 19th, @06:03PM

Couple things:

1) I have never seen my advanced page say that my "Flow Control" was ON. So not sure if the systematic degradation in my performance is technically "flow control." Probably a matter of semantics. But I do understand the model you are setting forth.

2) In Jan, I had a few days of sub-100kbps. Like three days straight. Escalated it, and the problem got better.

3) Sometime later in January the 4-midnight thing seemed to kick in.

4) My experience with degradation of service has always been a steady decrease. I have never not been able to get on. And I thought that the "burst-able" nature of network (if that is the right phrase) meant that everyone suffered when a transponder got very active. Hence the need for a FAP policy. Point being: I never experienced this poor performance during peak times.

My plan is to collected data on a few more days of throttle times, and call Executive Customer Care. Maybe it will all be for naught, but given #2 above, I am hoping that this problem will get better. What can I say: I am an optimist!

HN70000S | Pro | 83 W | 1430mhz
Forums » Satellite Connectivity » HughesNet Satellite[DW4000] ping to DNS IPs fails - help plese! »
« [DW4000] DW4000 gateway/transponder changes?  


Thursday, 20-Nov 15:06:55 Terms of Use | Privacy Policy | Hosting by www.nac.net - DSL,Hosting & Co-lo | feedback | contact
over 9 years online! © 1999-2008 dslreports.com.
page compression OFF
Most commented news this week
· [198] Obama FCC Selection Team Won't Make AT&T Happy
· [100] DSL's Not Dead Yet
· [77] Zone Alarm Pro Free Just For Today
· [75] Harvard Law Professor Sues RIAA
· [67] New Xbox 360 'Experience' Goes Live
· [54] CRTC Rules Against Indie ISPs In Throttling Dispute
· [51] Cable Grabbing 71% Of New Broadband Customers
· [48] Comcast DOCSIS 3.0 Hits Pacific Northwest In December
· [44] Comcast Offers 'Bare Bones' 768kbps VoIP Double Play
· [43] Comcast Buys San Fran Muni-Network
Most people now reading
· CRTC ruling coming Thursday Nov 20 [TekSavvy]
· Rocky - time to offer VPN service to all your customers [TekSavvy]
· CRTC ruling : 30 day notice and MLPPP? [TekSavvy]
· GE circline failure. [Home Repair & Improvement]
· MLPPP now seems to be throttled [TekSavvy]
· How would you take this? [General Questions]
· Must Read Article (THE MANCHURIAN MICROCHIP) [Security]
· Discussion on CRTC Non-Ruling thus far... [TekSavvy]
· 80 done, Naxx cleared.....can you say WOW...GG? [World of Warcraft]
· Half Life 10 years old today Nov 19th [PC gaming GAMES]