From owner-freebsd-bugs Thu May 30 10:26:59 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA00433 for bugs-outgoing; Thu, 30 May 1996 10:26:59 -0700 (PDT) Received: from mailhost.Ipsilon.COM (foo-5-10.Ipsilon.COM [205.226.5.12]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA00421 for ; Thu, 30 May 1996 10:26:53 -0700 (PDT) Received: from ns.ipsilon.com (cell.Ipsilon.COM [205.226.1.190]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id KAA15240; Thu, 30 May 1996 10:26:12 -0700 Message-ID: <31ADDA8D.7AB8@ipsilon.com> Date: Thu, 30 May 1996 10:27:41 -0700 From: Jerry Chen Reply-To: chen@ipsilon.com Organization: Ipsilon Networks, Inc. X-Mailer: Mozilla 3.0b3Gold (Win95; I) MIME-Version: 1.0 To: bugs@freebsd.org CC: olah@cs.utwente.nl Subject: a request for TCP enhancement Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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