Variation of packet size and interpacket time against Throughput

Aim

Recent experiments by Javier for 100mbit/sec back to back shows that strange loss patterns were found for low latencies - most likely due to buffering/coalasing by the stack (hardware/software). This experiment finds the criteria for udp tests that can perform at Gig rates

Method

A script was written to performance a series of tests varying both the interpacket time and the packet size of udp packets using udpmon. The scripts are;

do_packetsize.pl - a perl script to run udpmon with various packet sizes and present table
udpmon-cook.pl - perl script to tabulate udpmon data
do_packetsize-vs-interval.pl - wrapper script to run and create a 2d table of all udpmon variables

Equipment

The computers used for back to back tests were the Dell machines used for MB-NG initial testing. They are dual xeon 1.7 machines with 512megs running redhat 7.2 with a patched 2.4.16-web100 kernel (not that that should affect udp stuff).

Theorectial throughputs here.

Results here (xls).

Interesting things to note are:

1. it's actually quite difficult to reach 1000mbits/sec - even on udp. So chances are that for tcp, it's gonna be even harder.
2. I've only looked at packets upto 1500 bytes (TBC whether this includes the headers etc.)
3. Am i doing data rates wrong? on the tables, the values are actually lower than the recv rates...!!
4. We need to use very small intervals (<10usec) - however, the smallest obtainable value is about 10usec.. needs further investigation
5. The match between experimental and practical results is actually quite good :)

Anyway, to show how much difference there is, here's a simple graph of the theoretical throughput minus the actual recv throughput:

It's not bad at all - except for when we have very small latecies (in which case the actual latency should be used, rather than the requested...) and for very larger packet sizes... not sure about the larger packet sizes tho' :(

Wed, 23 July, 2003 13:07