Cablemodem download and upload speeds (followup)

An article by Plainsboro.COM owner Kennedy Lemke
November, 1999; updated with new data October, 2001

This brief article is a short followup to an article I wrote earlier: Experiences with Home-Based Internet Connectivity, Domain/Web Site Ownership, and Cable Modems.

In the summer of 1999, partially influenced by some projects at work, I became interested in knowing more precisely what kinds of bandwidth I was getting out of my cablemodem, both for download and upload speeds. I was also motivated in part wondering if I could get better service (in terms of bandwidth per dollar spent) by changing my current cablemodem service to DSL.

Over the years I had heard different accounts about cablemodem bandwidth from different people. From cablemodem supporters, I had heard that the MCNS standard actually supports about 40MB of downstream bandwidth (I do not use an MCNS-compliant cablemodem, though). The most notable complaint I heard was from DSL supporters, who stated that one of the differences between DSL and cablemodems is that as more customers began to use cablemodems in a neighborhood, the downstream bandwidth per customer would suffer.

I therefore decided to run a simple test to help me determine this bandwidth over a period of about a week or so, and also try to compare this with at least one current DSL offering in my area.

Description of the test

Basically what I wanted to do is at some regular interval, upload and download fixed-length files to and from the unix machine that sits in a bedroom in my house. I wanted to try to run a test in which internet traffic would be minimized (less traffic competing with bandwidth) so I could more accurately determine the capabilities of the cablemodem itself.

For this experiment, I needed to have two computers to exchange data between--one computer in my house behind my cablemodem, and another computer ``outside'' my house, preferably as close as possible in terms of router hops to my unix computer. I therefore needed some sort of access to both computers to allow for the exchanging of data.

The ``closest'' computer to my unix computer to which I had access that did not touch the internet was a computer located within @Home's network in which they allow users to have personal home pages. I signed up for this free additional service to gain access to the computer, put up a simple home page pointing back to my real home page on the computer in my house, then used the additional allotted space for my bandwidth experiments. Unfortunately, even though this computer was relatively ``close'' to me in terms of not touching the internet, it was still 12 router hops away, and located in California (my computer is in New Jersey).

Essentially what I did is wrote a simple ``expect'' script with a Bourne Shell front-end that would connect to the ftp server on the remote computer and upload, then download a couple files that I had created of size 1 Megabyte. I initially tried using both a binary file and an ASCII file to see if there was any difference between the two formats, but there was not.

I launched this program using UNIX's ``cron'' utility at regular intervals once per hour. I did not launch the program at the top of the hour because I did not want to chance competing with other bandwidth-hungry programs that might by chance be launched at that time as well. My program ran at some odd time like 23 minutes past the hour or some such to try to minimize the chance that I'd be competing with some other program that might likely be started at the top or bottom of the hour.

Results of the test

I ran the program for about a week or so, gathering statistics once per hour so I had 170 or so data points. There were a few odd occurrences where the expect script didn't run properly and I did not get good data for a particular hour, so I removed this bad data from the results, and ended up with around 140-150 data points for download and upload speed.

The results are on this graph. The graph's axes are: the X axis represents time (in hours); the Y axis represents bandwidth in Kilobits of up/download speed per second. Here's a description of what the colored lines on the graph mean:

The two blue lines represent the actual data that I collected about download and upload speeds. The top-most blue line represents download speed, and the bottom-most blue line represents upload speed.
The two green lines are really just reference markers: the top-most green line represents T1 line speed (1536Kbps), and the bottom-most green line represents the speed of a 56Kb modem.
The two red lines represent the maximum bandwidth you can get for a standard home DSL connection from Bell Atlantic in New Jersey for $49.95 per month. The top-most red line shows maximum download speed, and the bottom-most red line shows maximum upload speed.

Conclusions

The above graph represents real cablemodem download and upload data (blue lines), maximum DSL data rate for standard Bell Atlantic home DSL service (red lines) and green speed-rate reference lines.

I re-ran my experiment in August, 2001, after replacing my cablemodem and having Comcast upgrade the splitters inside and outside my house. Here's the resulting graph (which shows that download rate performance has NOT decreased over time dues to an increased number of home users, an argument that DSL enthusiasts often use against the use of cablemodems):

There were two things in particular that I learned from this experiment, and that the above graph demonstrates (at least to me):

First, I confirmed in my mind that I'm actually getting much better price performance (bandwidth per dollar spent) with a $400-per-year cablemodem instead of a $600-per-year reference DSL home service.
Second, I was quite surprised by the upstream bandwidth speeds of cablemodems. I had thought that upstream bandwidth on my cablemodem was much higher than what the results show (the results show upstream bandwidth being pretty consistent, around 140-150 Kilobits per second, or roughly the same bandwidth as three simultaneous 56Kb modems).

In the process of doing this experiment, I also was surprised to learn that DSL service also has a very large difference between upstream and downstream bandwidth.

And, finally, I was really unable to test the theory that downstream cablemodem bandwidth degrades with an increase in the number of users. I was unable to gather data about this because I'm not familiar enough with exactly how @Home's head-end is configured (like how many homes share a particular head-end site, and how many of those nodes might have been active at any particular moment during my testing, etc.). One note about this, however: at the time I ran the tests, I had been using a cablemodem for internet access for two years. I have not particularly ``noticed'' a difference in downstream speed as time has progressed. However, it might be worthwhile to run a similar experiment in a couple years' time (assuming the number of cablemodem subscribers will continue to grow) and compare these results with new results 2 years hence.