TxqueueLen Effects on Low Latency Network (MB-NG)

This will be a repeat of the previous tests, but across an empty low latency high throughput network. The characteristics of the network are 6ms rtt, 2.5Gb/sec POS. We will be testing this with GigE, single stream tcp with the default e4.4.12 settings.

Results

log files: xls tsv

Note: Results are incomplete: some tests didn't finish properly. So some of the results look a little strange.

we get slightly less throughput from the link. This is not surprising as tcp performance degrades with an increase in rtt due to the effects of the cwnd saw toothing. But we get pretty stable performance throughout the range of txqueuelen investigated.

Looking at the number of fast retrans and pkts being retransmitted shows that the stability in the throughput is matched by the stability in the retransmissions across the range.

While the back to back tests showed that the number of dupacks increase sharply after the optimal value. This does not appear to the be case. Given that the back to back tests gave a value of 300 for txqueuelen before we get no sendstalls, we would also expect similar performances for the end to end test. While there is a little structure in the region between 100 to 1000, it would be unwise to say that there are any effects of txqueuelen on the number of dupacks recieved.

The effects of the AIMD are shown above. Note that the dips are mostly due to missing data. Here we see the effects of DRS working well, with little deviation of the average cwnd value from the max and stable stdev on the value of cwnd.

Again, while there was a trend on the number of congestion Avoid and slow starts experienced on the back to back tests, there is no real structure or trend on the end to end results.

The back to back tests showed that the number of other reductions increases after the 'optimal' value of txqueuelen is reached. It also shows that the number of congestion signals decreases for the same period. For the MBNG case, ther number of the other reductions does appear to be increasing with txqueuelen, whilst the number of congestion signals remains constant.

The back to back case shows strange results whereby it was the sender's rx queue that showed errors (acks). The end to end case shows that it is the recv this time which is dropping packets. The number of errored packets is tha same as that of the number dropped; which again, implies that:

1. the sender sent malformed packets
2. the network corrupted the packets
3. the recv corrupted the packets

However, the number of packets corrupted is constant for the range of txqueuelens under investigation; implying that the effect of the loss is independent of the value of the txqueuelen set.

So why do we see errors on the recv this time instead of the sender?

Wed, 23 July, 2003 13:19