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