[netperf-talk] Netperf & iPerf

[Rick Jones]

> 
> We ran 2 tests, TCP and UDP stream tests.  The commands used were:
> netperf -H <hostip> -t UDP_STREAM -- -m 1024
> netperf -H <hostip> -t TCP_STREAM -- -m 1024
> 
> 802.11b does not do any sort of compression to the best of my knowledge.

If you want, you can create a compressed file of reasonable size and 
specify its name ina global -F option:

netperf -F <compressed file> ...

and netperf will fill its send buffers with data from that file.  It 
will still send the same set of buffers over and over again, but it will 
be something other than all zeros :)

> iPerf seems to only factor in data received at the application layer.
> Does Netperf throughput calculations include all data sent (network
> headers), or just what is received at the application layer?

Netperf is like iperf in that regard.  It measures only what goes 
into/comes out of the socket.  That is all something operating at the 
application-layer can do reliably.  (Otherwise, it starts mucking about 
with platform-specific stuff like statistics and it all goes downhill 
from there...)

> What other information could you use?

While it wouldn't matter for  UDP, does iperf set TCP_NODELAY by 
default?  Netperf does not, which means that TCP will be aggregating 
those 1024 byte sends of yours into larger (1460 byte?) segments.  One 
cannot really reliably force a given segment size with TCP, but 
generally, if you send < 1460 (or 1448) at a time and set TCP_NODELAY 
(test-specific -D option), that will cause the segments to carry just 
that quantity of data.  Generally.  You need to verify it with stats 
gathered outside of netperf (eg netstat or ethtool/lanadmin etc).

UDP doesn't have that - it just slaps a UDP header on whatever you give 
it, and hands the whole thing to IP.  UDP won't try to combine stuff, 
nor to split it up.

rick