72
Recv Send Send Socket Socket Message Elapsed
Size Size Size Time Throughput bytes bytes bytes secs. 106bitssec
16384 16384 16384 10.01 6.86
This is roughly the same throughput we saw with ttcp. netperf performs a number of additional tests. In the next test, the transaction rate of a connection is measured:
bsd2 netperf -H 205.153.60.247 -tTCP_RR TCP REQUESTRESPONSE TEST to 205.153.60.247 : histogram
Local Remote Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec
16384 16384 1 1 10.00 655.84 16384 16384
The program contains several scripts for testing. It is also possible to do various stream tests with netperf. See the document that accompanies the program if you have these needs.
4.2.3.3 iperf
If ttcp and netperf dont meet your needs, you might consider iperf. iperf comes from the National Laboratory for Applied Network Research NLANR and is a very versatile tool. While beyond the
scope of this chapter, iperf can also be used to test UDP bandwidth, loss, and jitter. A Java frontend is included to make iperf easier to use. This utility has also been ported to Windows.
Here is an example of running the server side of iperf on a FreeBSD system:
bsd2 iperf -s -p3000 ------------------------------------------------------------
Server listening on TCP port 3000 TCP window size: 16.0 KByte default
------------------------------------------------------------ [ 4] local 172.16.2.236 port 3000 connected with 205.153.63.30 port 1133
[ ID] Interval Transfer Bandwidth [ 4] 0.0-10.0 sec 5.6 MBytes 4.5 Mbitssec
C
Here is the client side under Windows:
C:\iperf -c205.153.60.236 -p3000
------------------------------------------------------------ Client connecting to 205.153.60.236, TCP port 3000
TCP window size: 8.0 KByte default ------------------------------------------------------------
[ 28] local 205.153.63.30 port 1133 connected with 205.153.60.236 port 3000 [ ID] Interval Transfer Bandwidth
[ 28] 0.0-10.0 sec 5.6 MBytes 4.5 Mbitssec
Notice the use of Ctrl-C to terminate the server side. In TCP mode, iperf is compatible with ttcp so it can be used as the client or server.
73
iperf is a particularly convenient tool for investigating whether your TCP window is adequate. The -w option sets the socket buffer size. For TCP, this is the window size. Using the -w option, you can step
through various window sizes and see how they impact throughput. iperf has a number of other strengths that make it worth considering.
4.2.3.4 Other related tools
You may also want to consider several similar or related tools. treno uses a traceroute-like approach to calculate bulk capacity, path MTU, and minimum RTP. Here is an example:
bsd2 treno 205.153.63.30 MTU=8166 MTU=4352 MTU=2002 MTU=1492 ..........
Replies were from sloan.lander.edu [205.153.63.30] Average rate: 3868.14 kbps 3380 pkts in + 42 lost = 1.2 in 10.07 s
Equilibrium rate: 0 kbps 0 pkts in + 0 lost = 0 in 0 s Path properties: min RTT was 13.58 ms, path MTU was 1440 bytes
XXX Calibration checks are still under construction, use -v
treno is part of a larger Internet traffic measurement project at NLANR. treno servers are scattered across the Internet.
In general, netperf, iperf, and treno offer a wider range of features, but ttcp is generally easier to find.
Evaluating Internet Service Providers
When you sign a contract with an ISP to provide a level of service, say T1 access, what does this mean? The answer is not obvious.
ISPs sell services based, in some sense, on the total combined expected usage of all users. That is, they sell more capacity than they actually have, expecting levels of usage by
different customers to balance out. If everyone tries to use their connection at once, there wont be enough capacity. But the idea is that this will rarely happen. To put it bluntly, ISPs
oversell their capacity.
This isnt necessarily bad. Telephone companies have always done this. And, apart from Mothers Day and brief periods following disasters, you can almost always count on the
phone system working. When you buy T1 Internet access, the assumption is that you will not be using that line to its full capacity all the time. If everyone used their connection to
full capacity all the time, the price of those connections would be greatly increased. If you really need some guaranteed level of service, talk to your ISP. They may be able to provide
guarantees if you are willing to pay for them.
But for the rest of us, the question is What can we reasonably expect? At a minimum, a couple of things seem reasonable. First, the ISP should have a connection to the Internet
that well exceeds the largest connections that they are selling. For example, if they are selling multiple T1 lines, they should have a connection that is larger than a T1 line, e.g., a
T3 line. Otherwise, if more that one customer is using the link, then no one can operate at full capacity. Since two customers using the link at the same time is very likely, having only
a T1 line would violate the basic assumption that the contracted capacity is available.
Second, the ISP should be able to provide a path through their network to their ISP that operates in excess of the contracted speed. If you buy T1 access that must cross a 56-Kbps
74
line to reach the rest of the Internet, you dont really have T1 access. Finally, ISPs should have multiple peering arrangements connections to the global Internet
so that if one connection goes down, there is an alternative path available. Of course, your ISP may feel differently. And, if the price is really good, your arrangement
may make sense. Clearly, not all service arrangements are the same. Youll want to come to a clear understanding with your ISP if you can. Unfortunately, with many ISPs, the
information you will need is a closely guarded secret. As always, caveat emptor.
4.2.4 Traffic Measurements with netstat
