What effects Speed? - Onlineeye can help you!

DSL and cable modems are fast, much faster than dialup modems, if you havn't used the internet over a DSL or cable 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 broadband lines sold?

DSL lines, following the tradition of 56k and previous 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 equation 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. Another way is to express speed as mbits.

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

places.. Thus, you may see your browser report a "Transfer rate:" being "XX KB/Sec", (along with the flying paper graphic as displayed to the right.

Audio and video playing applications tend to report the data rates needed or used, in terms of kilobits.

Aside: Browsers sometimes use this estimated transfer rate to predict the total time a download is going to take. (For some reason, transfer rates displayed by browsers are rarely accurate .. in this example, the transfer rate displayed of 194KB/sec was not correct - data can buffer up before the timers are started, and this causes exaggerated readings, especially when only part of the download has yet been received).

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

DSL Speed Maximum Visible
Transfer rate

256k ~28KB/sec

384k ~42KB/sec

640k ~69KB/sec

768k ~83KB/sec

Not so fast! Communications equipment vendors like to think in terms of low level ATM data rates without regard to the structure or content of the data.. ATM is a protocol for transferring data between two points. Internet uses ip as the protocol for communicating, therefore, and in particular, tcp/ip. So your data is going over your DSL line via tcp/ip over ATM.

TCP has an overhead in transmission that can be as low as 3%, but ATM overhead is more like 10% .. So you can expect to lose 13% of your purchased speed at least when counting application data transfer rate. Making up a rule of thumb here: Given a broadband line speed, dividing by 8 and taking off 13% is a reasonable estimate of the maximum likely data download speeds (in bytes of data) you will manage to get.

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.

While on this subject (poorly configured PCs), the usual other warnings apply.. insufficient memory (128mb is really the lower limit now for any windows install), underpowered processor (vintage PCs from the early 90s with less than 200mhz cpus are a potential problem area), an aging and unstable windows installation, accumulation of shareware, particularly SPYWARE and MALWARE - disinfect your PC from these nasties .. over-clocked motherboards that cause unusual problems .. 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, pop-ups keep happening, and your modem shows a lot of flashing lights indicating "data" even when you are not doing anything, then you've not got a stable system for experiencing top speed, especially from the point of view of the browser! Have a look at the Onlineeye Spyware Tutorial!

Enemy 2: Packet loss

If you see truly awful performance to a server, say, www.download.com, then test with a ping test first. go to Onlineeye-Ping and enter www.download.com
pinging tiny packets one a second at the destination. Watch the sequence numbers printed .. leave it running for a short time, say 30 seconds, then press control-c. Final packet loss statistics will be printed. If you see 5% or more packet loss, then TCP performance is going to be poor over this link. If no packets get through at all, you may have found a server that does not respond to ping packets, In that case, use tracert (traceroute), to identity one hop previous to the target server, and try pinging that instead.

As alluded to above, data transfer between you and another internet computer is mostly done using TCP. TCP is a protocol designed around the assumption that some packets may not get through. For the sake of example, let us imagine you are downloading data from cnet.com, and one of those many packets streaming down to you disappears en-route. Maybe a random neutrino knocks out a chip on a router for a microsecond, and the packet is dropped. TCP notices the missing packet in the stream of sequence numbers, and so does not acknowledge its reception.

The sender notices the lack of acknowledgement, 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 somwhere 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 favourite 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 favour. 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: 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.

Open Onlineeye Trace and use TRACERT, to work out at what point the congestion may be occuring, diagnose whether the problem is with the remote server or with your ISP.

Enemy 4: Many servers cannot currently offer high speeds to you

Server File Speed

ftp.netscape.com 1.6mb 310k/sec

ftp.aol.com 2.0mb 280k/sec

ftp.microsoft.com 5.0mb 67k/sec

ftp.myisp.com 5.0mb 66k/sec

Here are some results of a speed test to several reasonably well connected servers, at 3am in the morning (off peak):

In this example, microsoft and myisp.com would not provide the "broadband experience" to any user who thought they had speeds of 768kbps or more. Many servers offer speeds far slower than even this, because they are busy, and you are sharing their bandwidth with dozens of other people.

Enemy 5: Peak hour versus off-peak

US Internet rush hour seems to start around morning east coast weekdays, with higher intensity bursts at lunch east and west coast, and drops at dinner time.. then there is a final evening push that tails off around 1am east coast time.. During peak hours, packet loss problems, oversold bandwidth, and oversold servers, are emphasized and magnified. If your ISP is not managing its demand correctly, you are most likely to discover it during Internet peak hours.

Enemy 6: 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, multiplayer 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).

Again use our Trace Tool, it shows you all latencys

Aside: Why Stationary Satellites Suck

For Geostationary satellite systems, such as the ones providing internet access to Direct-TV subscribers, and other newer internet-in-the-sky providers, Poor latency (indirectly caused by the maximum speed of radio waves in a vacuum), screws up their business models for good. The distance to the satellite, is some 36,000 odd kilometers .. more actually, since they are over the equator, and you are probably not directly below them. The absolute fixed minimum round-trip-time for these systems is something more than the time it takes light to travel from the ground, to the satellite, and back down again, times two (follow the path to your intended server and back again to see why it is times two). This amounts to some 200ms (1 fifth of a second), at least. Increase this further, because you are talking radio waves, not light, because once on the ground, the regular internet latency takes over, and because of packet processing times, multiplexing, and error-checking, and you have the kind of delays that made older international phone calls so annoying, and make any highly interactive internet use impossibly slow.

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 havent read about that in the front page of your newspaper, it is still just a blueprint. (dont 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, xplot, 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 7: 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 isnt 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 8: 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 Atlantics 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 email 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 9: 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.