From owner-freebsd-current Wed Oct 4 15:43:28 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA07199 for current-outgoing; Wed, 4 Oct 1995 15:43:28 -0700 Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id PAA07194 for ; Wed, 4 Oct 1995 15:43:17 -0700 Received: from utis156.cs.utwente.nl by utrhcs.cs.utwente.nl (5.x/csrelayMX-SVR4_1.1tmp/RB) id AA12594; Wed, 4 Oct 1995 23:42:32 +0100 Received: by utis156.cs.utwente.nl (4.1/RBCS-1.0.1) id AA24073; Wed, 4 Oct 95 23:42:24 +0100 To: current@freebsd.org Subject: Re: lmbench 1.1.5 vs 2.2-current In-Reply-To: Your message of "Wed, 04 Oct 1995 13:00:25 +1000." <199510040300.NAA09750@godzilla.zeta.org.au> Date: Wed, 04 Oct 1995 23:42:23 +0100 Message-Id: <24072.812846543@utis156.cs.utwente.nl> From: Andras Olah Sender: owner-current@freebsd.org Precedence: bulk A few comments on the TCP lmbench results: In my view, the slight increase in TCP latency is partly due to the increased processing required by T/TCP. I haven't done any tests, neither did I count the extra instructions, so I cannot give a specific figure of how much is this overhead. I don't think it's significant. As for the throughput, I collected a trace with tcpdump. It turned out that the 0.21MB/s throughput is caused by an interference of the 16384 byte MTU of the loopback i/f and the Nagle algorithm. The transfer was running in a lock-step, when a few segments were sent and then the sender was waiting for a delayed ack (~200ms). This situation is described in a recent IEEE/ACM Trans. on Networking in the context of IP over ATM. Using the TCP_NOPUSH socket option increased the bw to 2.9MB/s on my noname 486/40MHz. I guess TCP_NODELAY would do the same. Andras P.S: I don't have lmbench at home (where I did the test), but a program bw_tcp by L.M. from 1994 which I believe is a precursor of the lmbench package.