Broadband Connections and Speed Tests
As I reported yesterday, Qweest had messed something up when provisioning my DSL circuit, giving me a slower-than-expected speed test results. Today, I get a call from Qwest saying “we found the problem, it’s been fixed and you’re modem should now be getting the correct speeds.” Sure enough, the WAN Status page on my DSL modem shows that it is training at 1536/992, which is wthin the specifications I am paying for. The question is: am I really getting this much throughput? The answer to that question is “yes and no.”
The WAN Status page of a DSL modem gives you a good idea of the maximum amount of speed your DSL circuit will give. This limit is based on a number of factors, including the speed level you have paid for with your ISP. You might be able to find out these limits on a cable modem as well, though my local cable company has blocked SNMP on the modems, making it difficult to find out what they are. If this limit is too low, as it was in my case, it’s a good indication something is wrong somewhere. With DSL, anywhere between the DSLAM and your location may be a problem, so a “Truck Roll” may be needed to correct some errors.
Once you’ve established the upper bound of what you should be getting in terms of speed, there’s the fact of verifying the speeds you are really getting. This is somewhat tricky because not all Internet connections are created equal.
In the DSL world, it’s typically a point-to-point connection between a DSLAM and your DSL modem. Various protocols are used over that link, though in the vast majority of cases, it involves PPP over Ethernet (PPPoE) and/or ATM protocols (e.g. PPP over ATM). These protocols are generally transparent to the end user, but the overhead these protocols impose, along with the overhead of TCP/IP itself, means that, on average, you’re getting about 80% of what you’re paying for in terms of speed, though even that can vary depending on the application in question. Refer to a white paper on encapsulation overheads for details. This means a 1.5 meg circuit should be giving you about 1.2 megs of effective throughput.
In the Cable world, there is also some overhead, but in theory not as much as DSL. By the raw numbers, Cable has about half the overhead that DSL has. This doesn’t take into account the fact that most cable networks, due to their architecture, often end up sending a significant amount of traffic to a subscribers cable modem that has nothing to do with commuicating with the subscribers computer at all. It’s hard to say how much extra overhead that ends up being. For the sake of argument, let’s assume there is a similar amount of overhead as DSL.
Keeping all this overhead in mind, some providers actually provision their service so that they take this overhead into account and “pad” the number they use to provision the service somewhat higher so they get an effective data rate along the lines of what they paid for. Most providers don’t do this, so you must take that overhead into account when using a speed test like at DSL Reports.
Bottom line: if you’re in the ballpark (about 80% of the rated capacity), chances are you’re getting the speeds you’re paying for regardless of the access method. My DSL circuit is within the ballpark now, so I presume it is working as well as it can.
