This document was written way back in 2000! Parts are out of
date now, but most of it remains accurate. It is preserved for posterity.
Speed
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 kilo
bits.
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. 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 (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 - see
Our Security Forum on how to 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!
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 an MSDOS prompt, and type
ping -t 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: Overloading of an ISP gateway.
ISPs dont 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.
Test your speed at peak
and at offpeak. If you notice marked and consistent improvements
at offpeak, then your ISP or possibly its upstream provider,
is congested.
|
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.
Open an MSDOS window (command prompt) and use TRACERT, to work out
at what point the congestion may be occuring, or download
Visual Route and
let it diagnose whether the problem is with the remote
server or with your ISP.
|
Enemy 5: 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 6: 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 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,
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).
PING some of your favourite 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.
|
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 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 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 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 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 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 favourite 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.