Slashdot Mirror
Computing Your Internet Speed?
"Here is the situation. On normal days, we get an average throughput of around 250kbp/s on some sites and 700kbp/s on others. This is done using bandwidth testers on around 20 different sites around the world. The 700kbp/s is around the best that we can get on a single computer with a single file download (from Microsoft, CNet, Tucows, Netscape, etc.) For multiple file downloads, we can get a max of around 1984kbp/s (that is if we download around 3-4 files or we download from the telecom company's test server.)
Is this an acceptable service? Initially, I thought having a bandwith this size will give us a download capacity of at least 1024kbp/s with an option to go full blast during the night. What are your experiences with links of similar line rates? What makes a single file download that slow. I know for sure that there may be congestion, router failures, routing instability, etc. If problem existed, it should be temporary (since we test on almost a daily basis.) I have heard from other forums that people can really download at E1 rates even in a Cable/DSL connection.
A hearty 'Thank you!' to you all for your help."
So if you see a broadband connection that offers {x} kbps/downstream and {y} kbps upstream, what kind of speeds are you likely to expect if you are getting your money's worth?
kernel.org has a bandwidth meter and is on a 100Mbps line. download from kernel.org and if you get around 1000kb/s you should be fine. note that you might be getting less because [1] theres some overhead in most protocols to transfer files and [2] most service providers dont deliver the full bandwidth anyway. its a fact of life and theres nothing you can do about it.
if you have a stringent contract with your provider you might be able to convince them to put a box in their office, one on your location and then pump data between the two to see if you can get to 2Megs between the two...or even 1 Meg sustained...and then fine them for the difference or ask them to charge less.. i doubt you will be able to do it unless you have a really good contract.
>For multiple file downloads, we can get a max
/dev/null
/dev/null
>of around 1984kbp/s (that is if we download
> around 3-4 files or we download from the
> telecom company's test server.)
An E1 connection is 2.048 mbit/s. 1984 kbit/sec
is 1.9375 mbit/sec. 1.9375/2.048 = 94.60%
utilization. Since that 2.048 mbit/sec is the
raw, layer 2 wire speed of the connection
and the 1984kbit/sec is the speed of a
layer 3/4 tcp/ftp transfer you're probably doing
even better than 94.60% since you are not counting
the overhead of TCP/IP and packet sizes.
Also, note that your ISP is only guaranteeing
you E1 speed over the link from you to them. After
that all bets are off. The only valid data
transfers would be from your LAN to theirs and
even then they should be done so that disk
issues aren't skewing the results.
This is what I usually do:
Inside ftp)
ftp> get bigfilename.tar.gz
note transfer speed
repeat exactly the same transfer. This should
make sure the remote file is now in disk cache
and should be served to you without any disk
accesses.
ftp> get bigfilename.tar.gz
now note the transfer speed here. It might be
a bit higher.
As you've also seen, single transfers won't max
out the connection. If you can run multiple
simultaneous tests and sum teh results you will
probably see slightly higher results.
That being said, I dont' think you have much to
worry about if you are getting 1984kbit/sec over
a 2.048 mbit/sec E1.
If it were me, I'd be running MRTG on the snmp
stats of your router so that you can see exactly
the amount of bandwidth being used. go to
www.mrtg.org, download, compile, install and
sit back. note that mrtg will report direct byte
counts so that you'll get a consistent layer 2
data transfer number rather than mixing layers.
This general issue goes under the name of (network) path characterization, and is a reasonably active research area. Usefully you can get several programs that will do their best to characterize the bandwidth and other attributes of each step in your routing. Nothing runs as fast as traceroute, but the numbers are likely to be interesting.
The best starting point for available programs that I have available offhand is the home page for pchar, one of the programs that does this. As well as pchar, the page has a fairly large collection of links to other similar and related programs. (Various programs use somewhat different approachs and math, and operate somewhat differently, so you may want to use several to cross check the results.)
With the cost involved here, there must be a substantial Service Level Agreement associated with it. Read it thoroughly. What is really promised, what recourse do you have if you feel the SLA isn't being met, and when a dispute arises, what mechanism is specified there to do the measurements? You can measure all you want, but when it comes to negotiating with your ISP, you'll have to play by the rules specified there, so you might see how it looks, and how it compares to your other measurements.
in my experience (over and over again, on many machines, on many many different access types) i can download a file * WAY * faster on my linux box than i can on my windows boxen.
as in your example, one file, 700, multiple might hit higer? well, I'll bet you're not on linux then, cuz in my experience, linux would have got you the full BW.
and always test from the closest box you can get to the inet access of course. you don't want your internal lan troubles slowing down your test.