Wednesday, July 25, 2007

Back of the napkin Network speed testing

I've been trying to compare iSCSI, NFS, and general network speed lately.

Awhile ago, my main Linux system was a dual PIII 500MHz. I was getting 20MB/s over the gigabit ethernet which seemed slow to me. At work I've seen 40MB/s to 60MB/s. I upgraded the server to an AMD dual core system and get 60MB/s.

My back of the napkin testing was pushing a gigabyte with dd:
time dd if=/dev/zero bs=1048576 count=1024 of=

GNU dd can also display MB/s.

I figure /dev/zero is the fastest source of bits. I can output to /dev/null to get the fastest data sink. Or local disk or NFS or SMB. But that still didn't measure just the network.

I found ttcp which sets up a client/server. On the sink I do ttcp -r > /dev/null. On the source, I pipe dd to ttcp -t . Netcat by Hobbit could do the same, but now there's a GNU nc that doesn't let you do -lp! I suppose I should just compile my own.

Something like:
On sink: nc -lvnp 5150 > /dev/null
On source: dd blah | nc -v -w 2 serverip


Bill McGonigle has this note about iperf. It looks interesting too.
Iperf's home
TCP tuning

The Iperf tarball has a test directory (read the README in it):
one side: perl server
other: perl client tests remote local | tee iperf.log
Tune some stuff
Run it again to iperf2.log
grep Mbits.s /tmp/iperf*.log | awk '{print $1, $(NF-1)}' | sort -n +1 | less
If iperf2.log is at the bottom, you got more megabits.

Is it accurate? I don't know. Does it help measure change? Yep. And that's what tuning is about.

No comments: