IEPM

TCP Stacks comparison with a single stream

SLAC Home Page
Bulk throughput measurements| Bulk throughput simulation | Windows vs. streams | Effect of load on RTT and loss | Bulk file transfer measurements | QBSS measurements | Internet 2 Land Speed Record
 Fabrizio Coccetti and Les Cottrell. Created 24 Feb '03, last update 19 March '03

 


From SNV to GVA | From SNV to AMS

From Sunnyvale to Geneva

We took measures from SNV19 (198.51.111.82, 4U machine, 4 Xeon-2.4GHz CPU, NIC 1Gbps)  and SNV14 (198.51.111.66, 4U machine, 4 Xeon-2.4GHz CPU, NIC 1Gbps)  to GVA5 (192.91.239.5) running: Stock TCP, Fast TCP, Scalable TCP, High Speed TCP.

For all measures  MTU=1500Bytes and txqueuelen=100packets.
We run pings during the measures to verify that RTT stays almost constant

Date, time PST Stack Kernel Avg Throughput in 1000s (Mbps) Avg Throughput in 80s (Mbps)
Feb 24 '03 11:40  Stock TCP linux-2.4.20  91+-21  59+-4
Feb 23 '03 23:40  HS TCP linux-2.4.20  929+-53  896+-31
Feb 23 '03 22:40  Scalable TCP linux-2.4.19  576+-219  381+-261
Feb 25 '03 11:00  Fast TCP linux-2.4.20  821+-73  739+-41

Fast TCP performance analysis

When we compare these throughputs with those measured with 1GE interfaces on other hosts at Sunnyvale, it is apparent that FAST TCP performance was poorer on SNV19. Our understanding is that FAST is not able to achieve high thruput on the Sunnyvale machine SNV19 because the SysKonnect card was plugged into a 33 MHz PCI slot. On machines where SysKonnect cards were in 66 MHz PCI slots, FAST had no problem achieving > 900 Mbps. I had verified this during our 10GbE test last week. I believe we were running into some bottleneck with the 33Mhz (64 bit * 33 Mhz ~ 2 Gbps) PCI that created a delay that was interpreted by FAST as queueing delay, hence the slower throughput. Cheng Jin.

Scalable TCP performance analysis

Scalable TCP is expected to reach almost the same performance of HSTCP.  An explanation of their different behavior, in our tests,  is given by Tom Kelly.  "The HSTCP experiments are conducted with the wad_ifq variable set to 1. The Scalable TCP experiments appear to not have the equivalent tx_moderate_on_txq variable set to 1. The reason Scalable TCP does not have this parameter set by default is that it ships with a txqueue default of 3000. If txqueue is reduced it is advisable to set tx_moderate_on_txq to 1 to achieve reasonable performance.".


 

From Sunnyvale to Amsterdam

We took measurements from SNV19 (198.51.111.66, 4U machine, with for Xeon-2.4GHz CPUs)  to AMS-97-17 (145.146.97.17) running: Stock TCP, Fast TCP, Scalable TCP, High Speed TCP.

For all measures  MTU=1500Bytes and txqueuelen=100packets.

We run pings during the measures to verify that RTT stays almost constant

Date, time PST Stack Kernel Avg Throughput in 1000s (Mbps) Avg Throughput in 80s (Mbps)
Feb 25 '03 11:40  Stock TCP linux-2.4.20  31+-6  35+-6
Feb 25 '03 14:30  HS TCP linux-2.4.20  221+-86  161+-114
Feb 25 '03 15:00  Scalable TCP* linux-2.4.19  23+-3  24+-3
Feb 25 '03 13:20  Fast TCP linux-2.4.20  149+-30  162+-28
* We run Scalable several times and got the same results, this poor performance has been explained by Tom Kelly.