Slashdot Mirror
Comcast Cheating On Bandwidth Testing?
dynamo52 writes "I'm a freelance network admin serving mainly small business clients. Over the last few months, I have noticed that any time I run any type of bandwidth testing for clients with Comcast accounts, the results have been amazingly fast — with some connections, Speakeasy will report up to 15 Mbps down and 4 Mbps up. Of course, clients get nowhere near this performance in everyday usage. (This can be quite annoying when trying to determine whether a client needs to switch over to a T1 or if their current ISP will suffice.) Upon further investigation, it appears that Comcast is delivering this bandwidth only for a few seconds after any new request and it is immediately throttled down. Doing a download and upload test using a significantly large file (100+ MB) yields results more in line with everyday usage experience, usually about 1.2 Mbps down and about 250 Kbps up (but it varies). Is there any valid reason why Comcast would front-load transfers in this way, or is it merely an effort to prevent end-users from being able to assess their bandwidth accurately? Does anybody know of other ISPs using similar practices?"
Doesn't Comcast advertise this "SpeedBoost" as a feature - the language in their ads is something like "get massive super speed for the first 10MB of a download, then it will revert to your provisioned line speed"... So, it actually *is* a good thing rather than something to pad bandwidth tests, and it does generally help your general user, right?
This is because of powerboost. As I understand it, powerboost makes the first 20MB download at a higher rate than your advertised bandwidth. Since bandwidth tests are done on such small files, you get a worthless result. The idea is that people who download lotsa of relatively small files get better performance, where as people downloading a lot of huge files like ISO images, full length movies, et cetera willg et initially good speed but after 20MB will feel like they are getting gipped.
Derek Greene
Sounds like they have simply optimised their network to favour "bursty" usage, for example web browsing. This would seem a sensible thing for a consumer ISP to do.
Some consumers may not notice the speed increase when downloading smaller files, such as text-based e-mails and simple Web sites with few graphics. However, customers who frequently download large files, such as software, games, music, photos, and videos will now download at speeds that are faster than ever before. For example, PowerBoost significantly reduces the time it takes to download a one hour television program. Comcast subscribers at the 6 Mbps tier would reduce their wait time in half - from 4 minutes and 29 seconds to 2 minutes and 15 seconds. And MP3 fans will be able to download music files as fast as 2.2 seconds! See more here
Full Tilt
Um, this isn't a new concept, nor is it particularly sneaky:
http://en.wikipedia.org/wiki/Token_bucket
I know that this is slashdot but I'll try to answer some of the OP's question anyway. Of course I won't do any original research myself, but rather rely on information from the previous posters or make things up as I go.
Q1. Is there any valid reason why Comcast would front-load transfers in this way?
Yes. Most requests from browsers are for short files. By upping the speed for short requests, pages will render faster. This is a plus for the user, as he spends less time idling. Long downloads on the other time are expected to take a while to complete; the user expects to be able to walk away from the computer for a while. Thus Comcast can argue that they have greatly enhanced the experience of the web browser by stealing a few cycles from the downloader. I would welcome such a plan as long as the ISO downloading speed is reasonable.
Q2. Is it merely an effort to prevent end-users from being able to assess their bandwidth accurately?
It would have that effect on a poorly designed bandwidth test. Bandwidth testers try to make the download size long enough to counteract tcp connection costs and to average over variations in download speed. Comcast has just given them another variable to take in to account. Interestingly, there are some test suites that are designed to detect what Comcast is doing and give them extra credit for it. They bill their tests as real world throughput tests. They want to indicate what the effective bandwidth is while browsing web pages that reference many images or javascript files.
Q3. Is Comcast cheating?
If Comcast is just doing this when accessing known test sites then they are cheating. If this is their policy for all connections then the worst that can be said is that they are optimizing their service to a particular class of users (surfers as opposed to downloaders). If you are in this category, then you should be happy.
PowerBoost only accelerates the connection if the average speed you've been getting over the past 30 seconds* is less than the speed you are rated at/paid for. So if you have a 6 Mbps connection, that's 768 KB/s max. PowerBoost will raise that to up to 2 MB/s for a little less than 15 seconds, making your average for the past 30 seconds equal to 768 KB/s. After that, no matter how many new connections you open, your connection stays at 768 KB/s. But if your connection gets interrupted/throttled for a few seconds, you may get another boost after it resumes, until you are back to 768 KB/s 30 second average again.
*it may be slightly more/less than a 30 second average. Boosts seem to last about 10-15 seconds, which would make sense with that number.
I can assure that they do absolutely do this, and it is really annoying.
It's really bad on uploads -- I just ran a test and I got 300 KB/s for the first 5 megs, then it degrades 100 KB/second over the next few megs, so that by the time you have uploaded 14 megs you are getting close to 40 KB/S in upload speed, and the connection is so bad that the shared digital phone line does not have enough bandwidth to have a phone conversation. Stop the upload and start it up again, and you get 330 kb/second, with the same degradation curve.
For downloads they do the same thing, but not so severely -- I downloaded a 67 meg file and it ran at about 750 KB initially, but then dropped to around 350-400 KB/S (according to the FTP app) about halfway through.
So for anyone using the connection for smaller file sizes (like the speed tests) you seem to get "blazing" speeds -- I ran the test at a couple of the internet speed test sites and they both think that I have 12000-14000 kb/s download speed and 2700 kb/s upload speed.
So if I didn't have any other way to measure it, I would think that I was getting way more than I paid for, rather than something that in reality is very pitiful.
If you want a commercial-grade link you expect to saturate, pay for it! Otherwise, you are stealing from other users and the ISP should throttle you to be fair to them.
In operating system theory, it is well known that a scheduling algorithm called "Shortest Job First" yields the least total waiting time. The SJF algorithm is usually implemented by giving a "new" job high priority, and then reducing the priority gradually as the job accumulates resource usage. The algorithm was developed in the 1960's to allow time-sharing operating systems to provide rapid keystroke response, while continuing to process large batch jobs in the background.
For communication systems, the same principle applies. The only difference is that the network is sharing a different resource (circuit bandwidth), instead of cpu time. The "new" connection gets high priority, and then that priority is reduced as the number of bytes/packets transferred over that connection increases. This allows rapid response for interactive applications, like browsing or editing, while also allowing the network to process large data transfers in the background. To apply it to datagram traffic, the switch just keeps a priority for each source/destination address-pair in cache, and any pair that is not in the cache is regarded as "new".
This has been pretty much standard practice in packet communication switching for a very long time. There is no surprise here, at least not to those of us who have not been doing communications network programming for a few decades.
http://www.dslreports.com/shownews/Slashdot-Keeps-Rediscovering-Comcast-Powerboost-91976