Existence of a critical speed X_crit for DCCP packet scheduling

Experiments to confirm problems due to scheduling granularity

New: The problem seems to be resolved in 2.6.22 - see here.

1 Background

Packet scheduling in CCID 3 is practically bound by a critical speed X_crit = s/t_gran (in Linux: X_crit = s * HZ).
Further background to this problem can be found here.

2 Experimental setup

Since only the packet scheduling behaviour, but not the dynamic changes due to receiving feedback, were of interest, a patch was applied which effectively set the inter-packet interval t_ipi to a fixed constant value in the range 50 microseconds ... 50 milliseconds. This ensured that t_ipi remained constant for the entire test run, allowing to see the impact t_ipi has on the packet speed.

Iperf test runs were then performed between two Linux hosts which each used the latest davem tree (2.6.20-rc5) with CCID 3 module loaded. Both computers used a scheduling granularity t_gran = 1/HZ = 1 millisecond.

On the sender (a dual-P3 700 Mhz Xeon with e100 NIC), the following command was run

iperf -X dccp -l1424 -c receiver -t20

after setting the t_ipi value each time via sysctl.

At the receiver (a P4 2.4 GHz with noname RTL 8139 card), the following analogous command was used.

iperf -X dccp -l1424 -s -t20

This affects sending packets with a payload of 1424 bytes for a test run duration of 20 seconds. Experiments were run on an isolated LAN, the only other connection was ssh (via xterm) to control the sender.

3 Results

The average Ethernet packet size of DCCP DataAcks was observed to be 1492 bytes (via wireshark). Throughputs for each value of t_ipi were noted and collected into a data file. This data was plotted using a gnuplot script. To contrast the results with the theoretically expected throughput, an `idealized throughput' was also plotted (green line), which was computed as follows:

idealized_throughput(t_ipi) = 1/t_ipi * 1492 * 8 [in bits/sec]

This gave the following graph.

Interpretation:

In the range up to 1/HZ = 1000 usec, the throughput is effectively constant (top speed of approx 94 Mbits/sec).
Between 1/HZ and 2/HZ the throughput changes non-linear with respect to t_ipi. This is probably due to scheduling inaccuracy.
From 2/HZ upwards the sending rate is controlled, but higher than the calculated/idealized throughput.

With regard to sending faster than allowed by t_ipi, it does seem that packets are already sent in bursts. The constant factor was determined to be 3.2 in this experiment, in the graph below the idealized throughput is normalized with regard to this factor.

4 Conclusion

There are two main points that this experiment has confirmed:

when t_ipi < t_gran, the sending transmit rate is effectively out of control
when t_ipi > t_gran, the actual/effective sending rate is about 3 times higher than intended.