Testing NW speed tricks

[Paul Thomson_2]

Does anyone have any small tricks / tests for sending data via ftp or similar to test network speed without having have the overhead of disk I/O when receiving the file ?

Im trying to test a GB connection between 2 servers.

[Peter Godron]

Paul,
ping ?
Send packages and reports on trip time.

[Duncan Edmonstone]

Paul,

I swear by netperf:

http://www.netperf.org/netperf/NetperfPage.html

The biggest advantage being, if you have any problems with it, the guy that wrote it contributes to the forums regularly! (Rick Jones)

Alternatively, you could use TTCP - there's a rather old version here:

http://hpux.connect.org.uk/hppd/hpux/Networking/Admin/nttcp-1.47/

HTH

Duncan

[rick jones · Accepted solution]

I certainly prefer it when people swear by netperf rather than at it :)

If you use netperf, reaching me may be more reliable via email, or better still the netperf-talk@netperf.org mailing list.

One can do tricks with sourcing from /dev/zero and sinking to /dev/null, but some of them (eg pipes) takes one away from normal FTP paths and system calls (eg send() versus sendfile())

WRT GbE, it is important to remember that _in and of itself_ GbE does _NOTHING_ to make data transfer any easier on the hosts. It still takes just as many CPU cycles to exchange a KB of data with GbE as it did with 100BT or 10BT. So, unless your systems were < 10% CPU util on any/all CPUs with 100BT, you won't get link-rate with GbE.

Now, there are features of specific NIC _implementations_ that can reduce host overhead - for example ChecKsum Offload (CKO) or interrupt coalescing, but again those are implementation specifics not fundamential aspects of GbE.

Also, while stock HP-UX ftp uses a TCP window (well socket buffer that then means TCP window) of 56KB that may not be enough to really get the most out of GbE. So, experiement with larger socket buffers - at _both_ ends of the connection if you can.