Computing Your Internet Speed?

john_uy asks: "I am from the Philippines working in a university. We currently have a frame relay E1 link to the Internet. The actual rate that we are subscribed for is 1Mbp/s (CIR) with an option to burst to 2Mbp/s (E1). Internet connectivity is very expensive and we pay around $9,000 every month. I want the best for the university and I just want to make sure that they aren't getting cheated." There are some hard and fast statistics in the article, so please read it to get the details. Based on these numbers, is the University getting the proper bandwidth for it's bucks?

"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

[Zurk]

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.

This says it all

[chuckfee]

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

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 /dev/null

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 /dev/null

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.

Re:This says it all

[M-G]

Definitely use MRTG to get an idea of your usage. There are also a number of utilities that can make estimates of pipe size between routers: pathchar, bing, etc. These so happen to be covered in a sample chapter on O'Reilly's site:

http://www.oreilly.com/catalog/nettroubletools/c ha pter/ch04.html

Re:This says it all

[G Money]

MRTG is a great tool for monitoring network usage as well as many other stats (CPU usage, Memory Usage, etc..) if you have the oids for it. I wrote a program called MRTGconfig which makes monitoring multiple routers, servers, etc.. easy to do. You can find it at mrtgconfig [sourceforge.net] . Hopefully that will make monitoring things easier.

Re:This says it all

[bte]

I'd also like to point out to keep in mind that you are in the Phillipines, and as such, there is no guaranteeing the bandwidth available into your country. I say this as someone who lives in Australia, and am constantly bemoaning the lack of bandwidth, not between our Co & ISP, but between AU & the rest of the world.

I'd say from the figures you're giving, you should be very happy, I know I would be with those kind of speeds :)

Re:This says it all

[morzel]

An E1 connection is 2.048 mbit/s. 1984 kbit/sec is 1.9375 mbit/sec.

I'm afraid I'll have to correct you on your calculations:

An E1 connection is 2048 kbit or 2 mbit - not 2.048 mbit/s.

E1 is actually a bundle of 32 64kbit channels (timeslots) over the same physical medium, where it is either possible to use all 32 timeslots for data (unframed E1), or where 1 64kbit timeslot is being used to transmit timeslot information to the interface placed by the telco (framed E1) - thus having an actual data rate of 2048-64=1984 kbit.

A 1984 kbit connection could well be what the university has ordered, if the telco is using 1 channel for timeslot synchronisation (very common here in Belgium).

Using a large compressed file over FTP for speedtesting is indeed a good way to have an indication of the linespeed, but doesn't cut it to get a good picture.

Using MRTG on your router (probably cisco 2600-ish) will yield far more correct results

Path characterization

[Chris Siebenmann]

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 [employees.org], 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.)

SLA Provisions?

[lythander]

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.