how-to block ads
|
CarlsDad
join:2006-07-10
Sedro Woolley, WA
1 edit | reply to sovtman
Re: Deliberate Limited Bandwidth 4pm to 12am ET
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! | |
selling hughes
@direcpc.com
| said by CarlsDad  :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
| reply to CarlsDad
said by CarlsDad :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. 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. That's interesting about getting your getting calls and suspending satellite sales. Brings a broader perspective to the issue.
My only contention with what you say is: I can set my clock by when my speeds are going to cut back. Will continue to check and document.
Tomcatt described his prime time speeds getting better in another thread. So I continue to hope. | |
sovtman
join:2007-04-20
Marlboro, VT
| reply to CarlsDad
said by CarlsDad : 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. Set my clock by it
February 19th, 04:03PM - 78/65 kbps
February 19th, 03:59PM - 624/65 kbps
February 16th, 04:02PM - 77/38 kbps
February 16th, 03:57PM - 728/88 kbps
February 15th, 04:01PM - 66/32 kbps
February 15th, 03:59PM - 605/38 kbps
It is interesting that my upload speeds stayed the same today. | |
selling hughes
@direcpc.com
| said by sovtman :said by CarlsDad : 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. Set my clock by itFebruary 19th, 04:03PM - 78/65 kbps
February 19th, 03:59PM - 624/65 kbps
February 16th, 04:02PM - 77/38 kbps
February 16th, 03:57PM - 728/88 kbps
February 15th, 04:01PM - 66/32 kbps
February 15th, 03:59PM - 605/38 kbps It is interesting that my upload speeds stayed the same today. As I said in my post above, my understanding is that flow control is applied to each transponder at times when usage patterns on that transponder show usage greater than available bandwidth capacity. Some time a go, someone from Hughes' engineering actually showed me the print outs from several transponders showing typical usage on those transponders each day. (My guess is that he would be losing his job for doing so if he were identified.) The print outs showed, for each transponder, at what times bandwidth demand was likely to be heavy and at what times it isn't. Based on those usage patterns, I'd be confident, Hughes has its flow control set to be enabled. I'd guess that the times vary from one transponder to another, but that, as your experience shows, for a given transponder, they happen at the same times in a regular pattern. Also, as I said above, the idea of flow control is to insure that, when there isn't enough available bandwidth to meet demand, that everyone will be able to get a share of that available bandwidth at lower speeds. Without the flow control, some would be getting faster speeds, but others would be unable to get on line. | |
sovtman
join:2007-04-20
Marlboro, VT
| reply to selling hughes
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. | |
sovtman
join:2007-04-20
Marlboro, VT
| reply to selling hughes
said by selling hughes :
I'd guess that the times vary from one transponder to another, but that, as your experience shows, for a given transponder, they happen at the same times in a regular pattern. Your information makes sense. Anticipating congestion, they restrict bandwidth.
BUT, as a long time HN user, I have to say that this is a new experience for me. For years, I have been use to having slower speeds in the evening, sometimes going down to 200-300 for a few hours. I even started using a d/l manager to collect things on the non-peak hours to be a good sat-citizen. But when I saw sub-100 speeds, I thought, FAP? or something's wrong!
Now, I am, in essence, pretty close to FAPed 8 hours a day. | |
selling hughes
@direcpc.com
| reply to sovtman
said by sovtman :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
1 edit | 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 | |
|
