Software to test networking performance between W2000-UNIX

[Aupee Jean-Francois]

Hi all,

I need a software to test network performance
between Windows 2000 and HPUX .
(Slow backup ...)
From Unix to Unix i use netperf but it's not easy to install netperf under Windows 2000.

Do you know another software to do this ?

Best regards.

[Simon Hargrave]

You can test simply the bandwidth with FTP. From the NT server, run FTP against the UNIX server, and transfer a largeish file. When done it will tell you Kbps. If you enable "hash" printing in FTP, you can see whether it stutters etc. If it does then there's potentially collisions on the segment, possibly caused by misconfigured duplicity.

[Todd Whitcher]

You can use ttcp between Windows and Unix, there is an option to use the discard port so you don't have to set up a client/server pair if you dont want to.

This site talks about ttcp for windows:

http://www.microsoft.com/technet/prodtechnol/windows2000serv/maintain/optimize/perftune.mspx

The beauty of ttcp over other network performance measurments is that it can use the discard port, port 9, to test. No need to logon or set anything up on remote system

# ./ttcp -stp 9 -n 100 15.17.7.253
ttcp-t: buflen=8192, nbuf=100, align=16384/0, port=9 tcp -> 15.17.7.253
ttcp-t: socket
ttcp-t: connect
ttcp-t: 819200 bytes in 1.62 real seconds = 494.39 KB/sec +++
ttcp-t: 100 I/O calls, msec/call = 16.57, calls/sec = 61.80
ttcp-t: 0.0user 0.0sys 0:01real 1% 0i+0d 0maxrss 0+1pf 379+1csw

Here is a link for nttcp,netperf and pkgen for hpux 11.11:

http://h21007.www2.hp.com/dspp/tech/tech_TechSoftwareDetailPage_IDX/1,1703,5969,00.html

Hope that helps,

Todd

[rick jones]

FTP does not test "networking" performance between two systems. It tests FTP performance between two systems, and that includes networking, filesystem and disc.

Ttcp was a good suggestion, I'll also not-so-humbly suggest netperf - http://www.netperf.org/ :) Although indeed, if you do not have a compiler for your Windows system that can make things harder.

You might also consider checking netstat -p tcp statistics, lanadmin statistics and maybe even taking a packet trace with the likes of tcpdump to see what your backup traffic looks like.

[Dave Olker]

Hello Jean-Francois,

As Rick said, FTP is not a good choice because it uses filesystem and disk resources as part of it's normal operation. However, if you must use FTP to gauge network performance, there are some ways you can try to bypass the filesystem/disk overhead and get a better sense of network throughput from FTP.

If you are connecting from a Win2K system to a Unix system and you want to test sending data to the Unix system, you could do the following:

ftp> bin
200 Type set to I
ftp> put /dev/null

This test reads the local file and writes it to the /dev/null device on the Unix system, thereby bypassing the filesystem and disk resources on the Unix system.

However, this test *will* include the time it takes to read the file from the local Win2K disk, so the thinking here is to run the command twice with the hopes that the Win2K box will send the file the 2nd time using the copy still in memory on the Win2K PC. Of course, this assumes (which is one of Rick's favorite words) that you have sufficient memory on the PC to cache the file between "put" attempts.

Assuming you have enough cache on the local Win2K PC, when you issue the same command again it will *hopefully* use the version in memory to send across the network, and in that test you won't be incurring any filesystem or disk overhead on either side, which will only leave the network throughput.

If you want to test pulling data from the Unix box to the PC you can repeat the same tests except use the command:

ftp> get NUL

The first time you issue this command it will read the remote file, thus incurring remote filesystem/disk resources, and write it to the NUL pseudo device on the Win2K box - which is the Windows equivalent of /dev/null. Assuming (there's that word again) you have enough buffer cache on the Unix system, if you issue the command again it will *hopefully* take the memory resident version of the file from the Unix box and write it to the NUL device on the Win2K box, thereby only using network resources.

I realize there are many caveats to this testing methodology, and Rick will probably hunt me down and throttle me for even suggesting this test, but I figured I'd throw it out there in the event that you only have FTP to work with.

Also, I thought some forum readers might be interested in the fact that NUL is the Windows equivalent to /dev/null. Perhaps most people already know this, but I just learned about it 5 minutes ago, so I figured I'd pass it along.

Again, the recommendation is to use NetPerf first, TTCP second, and in a pinch - FTP using the remote /dev/null and local NUL devices to bypass disk/filesystem.

Regards,

Dave

[Aupee Jean-Francois]

Hi Todd,all,

I found ntttcp under W2000 Driver Developpment Kit cdrom.

I try the following:

ntttcps -m 1,0,UNIX_ADRESS -a -n 5000 -p 9

I obtain the following for a 100Mb interface :

Throughput(Mbit/s)
94.733


I think it's good isnt-it ?

Do you know why i must use port 9 ?
the default port 5001 doesn't operate ...

Thks a lot...

[Todd Whitcher · Accepted solution]

Hi,

ttcp allows you to use the discard port (9) to test with as an alternative to setting up a ttcp listener on the remote system ( UNIX in your case ). Its helpful when you dont have access to the remote system to install ttcp etc. If you want to test with a listener on the HPUX you need to install ttcp/nttcp on the HPUX and start it up. I had some issues installing nttcp from the site I gave you earlier, I believe you need to install more of the developers toolkit to get it working. Anyway, here is a link to the pub domain for nttcp for hpux.

http://gatekeep.cs.utah.edu/hppd/cgi-bin/search

[Bill Hassell]

94Mbit/sec on a 100Mbit/sec LAN is extremely high, so your connection is fine. However, when you perform backups over a LAN, you must always look at the extremely slow byte rate (bit-rate/10 = byte rate approximately, not counting overhead). So the LAN theoretically could provide 10Mbytes/sec, much slower than most modern disks and also too slow for high speed tape drives like a DLT-80 or Ultrium. You can expect about 5Mbyte/s on a relatively quiet LAN with overhead.

The tape drive is likely the problem. It is too fast for the network and if you do not keep the tape drive busy all the time, it will run out of data to write, stop, backup, resync and take a running start to record more data. This requires seconds of time, thus lowering the throughput. Degradation of the tape speed ranges from 5:1 to 100:1. So a local backup might take 10 minutes but over the network, the tape drive is resyncing so many times that it's operating at only 1/100th normal speed (and wearing out the tape and drive mech at the same time).

Since your network is fine, you'll need to either:

1. Change to a slower tape drive that has an average write speed slightly less than 5Mbyte/sec so it will be kept busy or,

2. Change the LAN to a Gigabit connection. This means 1000Mbit end-to-end, no slow links in the middle).

[rick jones]

Even I will ass-u-me :) that sometimes you gotta do what you gotta do and that may mean making a "network" performance measurement with FTP. Heck, I had one fellow making a "network" measurement with FTP where he was piping-in contents of /dev/zero as the source - of course that completely changed the dynamic of FTP and didn't measure what a "real" FTP would have done.