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
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?
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
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
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
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,
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
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
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
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.