LAN txqueuelen tests - 14th February 2003

Purpose & Method

In a more controlled environment, the study of txqueuelen alteration was performed. This involved setting up mbng2 and mbng3 back to back on wan. TCP iperfs were set up between the two hosts and the txqueuelen in /sbin/ifconfig was altered and the results plotted.

A baseline study showed the following sendstalls (monitored with web100 2.1) for a 5 minute transfer back to back using iperf tcp set to 1m windows (much greater than required).

This was performed using the default settings of 100 txqueuelen. This equals to roughly 260 sendstalls in 300 seconds, or just under 1 a second.

Results

Experiment 1: Small txqueuelen

For various txq settings, a 2 minute back to back iperf was conducted from mbng2 to mbng3.

table: tsv

logs: zip

Hmm... doesn't seem to make much difference back to back!

However, looking at the number of sendstalls experienced...

Shows that the number of sendstalls decrease dramaticallly (it's another cumulative graph). One thing to note from this is that there are no differences between the even value and the previous odd value. There is also a clumping of sendstalls as we have a txq >= 14.

The affect of the sendstalls doesn't have much affect on throughput as you can see from the graph before. This is most likely due to the effects of the very small rtt.

Experiment 2: large txqueuelen

Same tests were repeated (2 minute tcp iperf) back to back, but this time with larger sized txq's.

Again, it doesn't seem to make any difference what so ever to the throughput results. I'll make the assumption for now that this is actually due to the small rtt value.

We can see that there is certainly a difference in the number of sendstalls experienced. There does seem to be some anomoly around the 100 to 200 txq tho' :( repeating the test should the results to be about the same.

Zooming in, shows some of the structure of the traces. We can see that are really do lower the number of sendstalls as we increase the txq len.

As txq lengths of 2000 and above, we experience absolutely no sendstalls during the transfer.

Summary

Hmm... no real equation can fit to this i suspect... points to note:

• seems to fall off quite well apart from the funning kink at about 15...
• appears quite linear from 15 to about 1000
• no advantage after 2000.

Conclusion

Increasing the txq length does reduce the number of sendstalls experienced by a tcp connection. By increasing this value, we can aid tcp performance (although this needs to be prooved along a WAN link). There is no benefit in increasing the size of the txqueuelen beyond 2000 (at least on a back to back configuration). As we are dealing with the sending rates, which are related to the ack rate, which is the smallest possible in a back to back configuration, it should not need to be increased beyond 2000 units in a WAN environment either.

There are issues with tcp burstiness which may infact require the txqueuelen to be increased to a larger value. This is research in progress.

Wed, 23 July, 2003 13:07