Jan Allman wrote:
Rick,
I'm tring to see how much data I can send over a point to point
Ethernet link using UDP (i.e. as quickly as possible). I had a repeating
loop of "sendto" calls. I was using Ethereal to report statistics on the
throughput I was achieving.
Repeating your test on my machines (between one dual 2.8GHz machine
and one 3GHz machine)...
netperf -t UDP_STREAM -H 192.168.0.6 -c -C -- -m 1472
UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.0.6 (192.168.0.6) port 0 AF_INET
Socket Message Elapsed Messages CPU Service
Size Size Time Okay Errors Throughput Util Demand
bytes bytes secs # # 10^6bits/sec % SS us/KB
65535 1472 10.00 811659 0 956.0 15.61 5.410
65535 10.00 802851 946.6 49.18 4.201
Is this telling me I am able to get 950Mbps of throughput? (I've
never used netperf before)
Yes - it is saying that the netperf side (the send_udp_stream() routine)
believed it was sending at a rate of 956 Mbps, and that the netserver
size (the recv_udp_stream() routine) a subset of that data at a rate of
946.6 Mbit/s. Of the 811659 1472 byte sends netperf made, 802851 of
them were received by netserver - the rest were lost somewhere between
the two.
You can use the -f option to change the output units - k, m and g give
power of ten bits per second; K, M and G give power of two bytes per second.
When I use Ethereal it calculated an "Avg.
MBit/sec" of 177.592 (linux kernel 2.4.24, libpcap 0.8.3, ethereal
0.10.7). Do you know why this is so much less than the netperf
reports? Is Ethereal reporting a low rate because it is dropping data
due to having to maintain its GUI? Is Ethereal displaying a low
throughput rate due to libpcap limitations for 1472 bytes sized
frames?
Well, you could check if it was ethereal's GUI by using tcpdump - I'd
suggest a tcpdump -w <foo> that you then post-process with ethereal.
If it then reports closer to what netperf reported, you can ass-u-me it
was the GUI overhead. If it still reports what ethereal was reporting,
you can ass-u-me it related to the libpcap and below not keeping-up.
rick jones
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
