Speed

DSL and cable modems are fast, much faster than dialup modems, if you haven't played with a DSL line before, then they are faster than you've imagined them to be.. but are they as fast as the ISP or Telco is telling you they are?

How are DSL lines sold

DSL lines, in the tradition of modems, are sold in Kilobits per second. They are sold by naming two speed quantities.. download speed and upload speed. The ISP will put more emphasis on download speed, sometimes not even mentioning upload speed at all as if that side of the twisted pair is inconsequential to you, when in fact, upload speed can be a critical part of the performance puzzle.

The typical speed quote comes as a three and sometimes four digit number, often with the same or a smaller number alongside it. This is a Kilobit per second speed rating.

How do DSL Kilobits per second translate to speed?

Browsers and other file transfer agents tend to show speed in terms of KiloBytes per second, usually with one or two decimal

So.. Bytes and bits? I just divide by 8 then?

The ideal world

In an ideal world, you should be able to see in your browser download window, during a sustained transfer, a rate equal to your purchased speed, divided by 8 (to get Bytes), less 13% (TCP/IP and ATM header overhead). It is unlikely you will ever see that speed though, and the rest of this article explains why.

The real world - Speed Enemies

Enemy 1: Badly configured PC

The single most common cause of poor performance is a windows PC that is in poor shape for broadband. Rather than go into all the details here, since we have a complete tweak section, we refer you to the online tweak testing applet , and associated notes and forum.

While on this subject (poorly configured PCs), the usual other warnings apply.. insufficient memory (64Mb is really the lower limit now for any windows install), underpowered processor (less than 133 MHz is a potential problem area), an aging and unstable windows installation (accumulation of shareware and applications, in various state of disrepair), that can only really be cleaned by a format/reinstall.. over-clocked motherboard that causes unusual problems with internal DSL modems and/or ethernet cards.. the list is endless really. If you experience frequent application crashes or blue-screens, the disk churns like crazy as you switch between applications, windows reports warnings about virtual memory becoming low, then you've not got a stable system for experiencing top speed, especially from the point of view of the browser!

Enemy 2: Packet loss

The sender notices the lack of acknowledgment, and must retransmit the lost data. The retransmission procedure adds to the amount of data flowing over the connection, and may also be lost, the receiver if it does not get the missing data quickly enough can start to fill up its buffers waiting for the old data to appear, and these full buffers will signal the transmitter to slow down. TCP has many and sometimes conflicting designs to cope with the vagaries of different kinds of link performances, but in the end, consistent packet loss somewhere en-route devastates TCP throughput from its theoretical maximum, even though it may be one packet in 10 or 20 that is being dropped.

So that is why we care about packet loss? If there is a _continuous_ packet loss between you, and your favorite site, it doesn't matter what you do, your TCP based data (web pages or file transfers) are going to slow down to a crawl. In this case TCP is not working in your favor. Your data is getting lost at the same rate, no matter what transmit speed you are running at, and yet TCP is slowing down. The result of this is you get stuck with a poor speed because of gridlock beyond your cause or control.

Enemy 3: Overloading of an ISP gateway.

ISPs don't purchase as much upstream bandwidth as the sum total of all of their downstream users. This is not in itself a crime, why should they pay for large pipes that are only used when you choose to get online? The trouble comes when they over-sell to the extent that peak bandwidth aggregated demand from their users gets near to the maximum capacity they have purchased. We are the end of a food chain here.. many of us connect to one ISP, and many ISPs connect to a tier 2 backbone, and many tier 2 backbones connect to a tier 1 backbone... at any of these points of aggregation, there may be congestion due to oversold bandwidth. Note: the over-selling may not just be bandwidth, they may over-sell router cpu or memory capacity also.. putting too many users on one router can cause maximum cpu usage at peak hours and therefore slow-downs, despite bandwidth being available.

Enemy 4: You are not home free when your data gets to a backbone.

The Internet can be imagined as a tree, with root system the servers, and leaves the users. The trunk sap lines are the backbones. All "leaves" must currently get nutrient direct and on-demand from "roots", the trunk does not store anything.. Assuming you can get to an Internet backbone easily, then follows (but in reverse) the same potential problems reaching the server, although the larger and more popular the server, the more likely it will be located close to a backbone, so there is consequentially more chance that you are home free and your requests are serviced at full speed. There still could be packet loss problems, or over-sold bandwidth between the server and its connected backbones.. even between different backbones! That is where traceroute and similar tools come in.. if ping shows there is some problem, traceroute may show where in the chain between you and your destination the problem starts, and its nature.

Enemy 5: Many servers cannot currently offer ADSL speed to you

In this example, Microsoft and Flashcom would not provide the "ADSL experience" to any DSL user who purchased speeds of 768Kbps or more. Many servers offer speeds far slower than even this, because they are busy, and you are sharing their T1 or a T3 with dozens of other people.

Enemy 6: Peak hour versus off-peak

Enemy 7: Hop counts, latency

Hop count is the number of routers your packets must navigate before they reach the destination. With a small ISP, things are thankfully simple :Your data goes to the ISP via your DSL provider network, then it goes to the Internet, at or very near the ISP network operations centre.. knowing where your ISP gateways to the Internet is going to tell you whether or not there will be many hops between you and the data you need.

With larger ISPs, it becomes more difficult.. they have multiple gateways to the Internet, and may change routing every now and again.

The more hops between you and your destination, the more latency (traveling time), and the more potentially overloaded or troublesome Internet hops you may have to cross. Latency is also a function of link speed.. comparing link A and link B, if it takes half the time to transmit a data packet over B than A, then latency is likely to be roughly half on B than on A. The replacement of slow modems, with DSL lines has contributed to huge drops in latency.. from 150-200ms down to 20ms for small packets, and from 200-400ms down to 50ms for large packets.

For a great article on why latency is important, and misunderstood, read this paper by Stuart Cheshire .

Low latency is very important for interactive applications, telnet sessions, multi-player games, but high latency can also make the web feel more sluggish to "get going".. a 200ms latency, can add 200ms to the total download time for the page for every eight or so objects on that page! Some complex pages contain dozens and dozens of components to download, making a high latency connection feel very slow. (Browsers download things from websites by default at about eight objects at a time, older browsers came setup for only four, each time one download finishes, that channel is idle whilst it waits for the next request to make it over to the remote server, and the data to turn up on the way back).

PING some of your favorite servers. Compare
geographically remote ones to near ones. You are looking at
ms (millisecond) ping times. Ideally, nearby servers (in your own
city for example) show much lower latency than far servers.
If you find specific servers show a surprising and consistent high
latency, check using TRACERT to see if the number of hops are not
excessive. You should expect to be at least 7 hops away from
large nearby servers other than you ISPs, and <15 hops to most
servers in the US.
Compare ping times to different cities. A good set of hosts is
available at the Internet backbone company Level3.Net:

   ping hsipaccess1.xxxx1.level3.net
(in both cases, that is "1" as in the number one)
Where xxx should be replaced by your choice of:
Detroit,Chicago,SanFrancisco,Washington,
Atlanta,Houston,LosAngeles,SanDiego,Denver,
Philadelphia,NewYork,Dallas,Boston,
SanJose,Denver,Seattle

This will give you your latency, to a major NAP (network access point) in that city.

Aside: Why Stationary Satellites Suck

There will be at least a years notice before a low earth orbit (LEO) Internet in the sky satellite system gets off the ground. If you haven't read about that in the front page of your newspaper, it is still just a blueprint. (don't forget .. the last LEO system, Iridium, is busy burning itself up in the upper atmosphere as this is written)

TCP Slow Start

The TCP protocol is designed not to assume a link is ready to accept data at full speed. It therefore uses an algorithm called slow start, rather like a race driver getting a green light and accelerating slowly away, in case something blows up in his engine. Under normal circumstances, within a few seconds of packet exchange, two TCP devices are talking at nearly the maximum speed of the link, unfortunately, those slow starting few seconds are going to reduce the average throughput reported by programs.
Here are two graphs of what happens when two TCP stacks are incompatible in their handling of the complicated speed negotiation at the beginning of a sustained transfer. We show these just to illustrate one of the many things that can go wrong when two different implementations of TCP try to talk to each other, that may subtly or markedly reduce reported speed.
Graph showing the transfer over time of one recorded TCP connection .
For those interested, these data transfer graphs were generated from the magic combination of TCPdump, TCPtrace, X-plot, Ghostscript and the ppm toolkit. They show a Windows NT server talking to our Linux web server. The plots reveal the difficulty the two machines have at the start of the download.. rather like two dancers stepping on each others toes, but once resolved, the transfer proceeds smoothly. This problem was reproduceable, and nothing to do with congestion, latency, routing or any other "environmental" factor.
Problem area zoomed further .

Enemy 8: Routing Problems

Routing problems can cause weird drops in speed. 99% of the time, your data packets travel along the same path upstream as back down, but it isn't necessarily so. Sometimes there are router problems and packets can start taking alternate routes. The worst case is that alternate packets can take alternate routes in the same TCP conversation... this plays merry hell with the TCP transmit speed calculations and performance drops fast.

Enemy 9: Poor Upload Speed

Back to upload speed.. what is it good for? A download is not just a download of data, the aforementioned protocol involved in downloading data requires a back channel to communicate messages to the sender... as in conversation, it is very hard for a speaker to know he is being understood if he does not get a fairly continuous stream of affirmations by the listener.

Your maximum upload speed is something you need to include as a possible factor in reductions in download speeds. Lets take Bell Atlantic's 90/640 ADSL product as an example. For every packet received on the download channel, a 40 byte packet must come back (a zero data length TCP packet). If the link was running at full speed 640Kbps, you would need a back channel capacity of more than 640 x 6% = 40 .. so your return channel is half used for just a download! for Bell Atlantic 90/1600 ADSL, things are even more dire, and you may have trouble seeing 1600Kbps! If you actually wish to transmit any _data_ on your upload channel (say, an e-Mail with large attachment or someone is using your FTP server, or taking an mp3 from your Napster cache), then download speed will be severely impacted..

Enemy 10: PPPoE overhead

PPPoE adds a little bit more header to every packet, but it adds quite a bit more CPU requirement to the process of sending data. Depending on the PPPoE stack in use, and how fast your ADSL was before PPPoE arrived, you can expect to see a 5-25% degradation in maximum speed. Ameritech recognized this when they 're-badged' their ADSL product down to 768Kbps after they rolled out PPPoE.

Conclusion

DSL speeds are quite a leap over modem speeds, a leap that puts you at the end of a line capable of going faster than possibly the majority of servers you might wish to use. A T1 has long been the favorite line to host a corporate server on, and the top SDSL speed is the same as a T1, and the top ADSL speeds are a lot faster than T1... you are almost surely not going to be using a server alone, hence you are limited by it, not by your DSL line.

A regular modem can be compared to a fogged up window, through which imperfections in the Internet connectivity are hard to spot.. DSL can give you a much cleaner view, and you experience a lot more of the uneven nature of net performance. Overseas sites that used to seem little slower than domestic ones, now seem to crawl.. and if your ISP is overloaded or your part of the Internet is congested, the results are more immediately visible to you.

If you are getting anything like maximum theoretical speed on your DSL line, then you should count yourself lucky, as you have chosen a good ISP, a good DSL network, the server you are talking to is well connected and uncongested, your windows PC (if you are using windows) TCP settings are tuned correctly, and there are no trouble spots between you and your destination. Enjoy.