Ask Slashdot: Holding ISPs Accountable For Contracted DSL Bandwidth 345
mcleland writes "I'm not getting the bandwidth I paid for from my DSL connection. My '3mbps' fluctuates between about 2.7 during the day down to 0.1 or 0.2 in the evening according to speedtest.net. Let's assume DSL is the only viable option for broadband at my house and I can't really move right now (rural area, on north face of the mountain, no cable service, very poor cell coverage). This was discussed 6 years ago, but I'd like to see if there are any current thoughts on whether I'm just stuck or if there is some way to make the ISP hold up its end."
What did you sign up for? (Score:5, Interesting)
Re:Live with it (Score:4, Interesting)
I don't think it was the 2.7 Mbps that was the concern, but rather the "down to 0.1 or 0.2 Mbps in the evening". That's either the line retraining to the lowest possible fallback speed (bleed-through from somebody else's line, perhaps) or a massively over-committed upstream pipe from the DSLAM.
Re:What did you sign up for? (Score:3, Interesting)
DSL is very hard to guarantee any numbers. You won't know the speed you'll get until after installation. It depends upon the quality of the lines (including in your own home), distance to the telephone company's DSLAM, etc. I had ADSL with two companies and neither one ever gave a guaranteed speed. However I did call one once to report low speed and it did improve quality after that.
Re:The answer was the same 6 years ago: (Score:5, Interesting)
Also check for local agencies.
Where I live, companies have been granted a monopoly by the city to provide telephone and cable service. Years ago, I was having some problems with my cable and was getting nowhere dealing with the cable company. That's when I discovered that the city actually paid someone to keep track of these sorts of issues and try to get them resolved. I contacted him and let him know the issues I was having with the cable company. He said he'd look into it. The next day, I had the folks at the cable company calling and saying how they'd like to get to the bottom of this problem. A couple days later, everything was hunky-dory.
Now, I live in a denser area, but there may be an equivalent person in your town/city government.
Re:What did you sign up for? (Score:5, Interesting)
Yes that is true, but the quality of your lines do not tend to change based on time of day (although, I have seen them change based on the weather before :). This is clearly a grossly oversubscribed uplink from the DSLAM to their backbone (or their backbone to their upstream provider / peering point).
Simple, just multiply by the variable until maxed. (Score:5, Interesting)
I have yet to see a DSL provider that does not state in very small print that the connection is "burst" or "variable" or "up to".
Burst is actually kind of silly. It really screws with data rate prediction required to get smooth performance in multi-player games. So, you start playing, the game figures out the rates, everything's smooth, then the burst is over, you lag all to hell, as the game has to renegotiate the data rate. For downloads, no big deal, but for real time stuff like games or voice/video chat this is a problem... It's not that you connection is too slow after the throttle either, after a while you'll get smoother connection -- It's that initial period of "increased" performance that's screwing up the rate guesstimation.
OK, so here's the silly thing: If you have "bursting", start a D/L of a largeish file. Then, watch the data rate drop after a little while. Now, hit the pause button on the download. Wait a sec, then resume it. Tada! You can burst the whole D/L by re-establishing the HTTP connection -- Not that the pipes have changed at all, just that they throttle on a per connection basis. (How else would you do "bursting"?)
So, two things:
0. Use a Download Accelerator. I use the Firefox plugin: DownThemAll [mozilla.org]. Acceleration works by opening multiple connections to the source at different parts of the file -- per connection throttle? Increase connections until max bandwith is reached, heh. If one part of the file gets done before the onthers, it splits a remaining segment and starts a new connection; That actually boosts DL speed even more. It's too bad DTA doesn't have an option to open N connections each only S size chunks, and roll across the file... Guys? There's a viable plugin idea if you need one.
1. My new game client / server code has a "rolling" connection system to bypass time based throttling (bursting). It's all about the port numbers -- that's how they identify the connection. In my games I use UDP, but it falls back to TCP; Point is: this also works on TCP. What I do is open a new connection every once in a while, and send some data across it while the current connection is open (It's just port number changing in UDP). I track the speeds and latency of each connection (port number), and detect the timer duration at which the throttling happens by tracking data rates, then I set the connection roll over rate to be less than that. So, on non bursting lines, rolling rarely happens. I can also have more than just two ports open -- I can max my neighbor's 10Mbps bursting DSL line with just 6 concurrent rolling connections. Note: The server port doesn't have to change, seems that most per connection throttling is based on client port number.
It's weird, but shorter connections seem to cope with buffer bloat a bit too; Not sure why...You'd think the buffers were connection independent? Tuning the data rates helps combat BB lag even more though.
I'd write a RFC for this maximal bandwidth optimization technique, but let's just keep it between us geeks, OK?
P.S. My game server defaults to port 80, and displays a simple TCP / HTTP / HTML page about the current game in progress and where to D/L the game if you hit it with a browser. If you hit it with the game client, then the client's HTTP header tells the server to go into game protocol mode. Note: it's not a full HTTP 1.1 stack, just canned response with inserted real time stats, to reduce attack surface while giving the server a bit of info for HTML browsers & apps. Yeah, that's kind of weird eh? Except when you consider that to a deep packet inspection my game protocol initially looks like a "high priority" TCP/HTML query... heh.
Tap into America (Score:3, Interesting)