Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 30 May 1996 10:27:41 -0700
From:      Jerry Chen <chen@ipsilon.com>
To:        bugs@freebsd.org
Cc:        olah@cs.utwente.nl
Subject:   a request for TCP enhancement 
Message-ID:  <31ADDA8D.7AB8@ipsilon.com>

next in thread | raw e-mail | index | archive | help
Hi, there,

I notice that there is a difference in TCP implementation between 
Solaris 2.5 and FreeBSD 2.0.5.  When I run ttcp to keep sending packets 
over ATM using 64K-1 window size, the frequence of ack is different.  

In FreeBSD, the ratio of the total number of ack's (including window 
updates) to the incoming number of TCP packets is about 1 to 2.1.  That 
is, under heavy traffic, FreeBSD TCP sends out 1 ack or window update 
when it receives, on the average, 2.1 packets.  In Solaris 2.5, it sends 
out 1 ack when it receives, on the average, more than 20 packets.

According to page 277 of Steven's "TCP/IP Illustrated, vol 1", BSD tends 
to "ack every other segment".

Does Solaris 2.5 implementation violate the TCP spec?
 
It seems to me that Solaris 2.5 is making better use of the resources.  
Well, who knows.  Maybe they try to make up for the bad thruput of SBus. 
 But I think in general, too many ack's or window updates may hurt the 
TCP thruput, at least in some benchmark cases.  Below are some of the 
reasons I can think of

1. There will be more interrupts for the processor to handle.  The top 
half of an OS (the xmit side) may be blocked while the CPU is processing 
interrupts.  The cache hit rate may also be lower (this is just a 
guess).

2. The incoming ack's and window updates will cousume some i/o bus 
bandwidth.  Bus arbitration is not free (hidden) in some buses such as 
SBus.

3. For high speed networking devices such as ATM, there is usually 
limited amount of slave memory on an adapter card.  The recv side 
usually has higher priority over the xmit side to DMA packets or cells 
to main memory to prevent overflow in FIFO or slave memory.  

In short, the ack/window update on the recv side will compete with the 
"real tcp data" on the xmit side for CPU, cache and bus usage and, 
unfortunately, the recv side usually has higher priority.

So, should FreeBSD be modified to have similar ack strategy?  Please 
correct me if I am wrong.  Thanks.

Jerry



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?31ADDA8D.7AB8>