From owner-freebsd-hackers Sun Jan 11 14:55:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA15220 for hackers-outgoing; Sun, 11 Jan 1998 14:55:50 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA15213 for ; Sun, 11 Jan 1998 14:55:31 -0800 (PST) (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id PAA14794 for hackers@freebsd.org; Sun, 11 Jan 1998 15:35:42 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id PAA12853 for ; Sun, 11 Jan 1998 15:34:50 -0700 (MST) Date: Sun, 11 Jan 1998 15:34:50 -0700 (MST) From: Marc Slemko To: hackers@FreeBSD.ORG Subject: Re: why 100 byte TCP segments? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk Yup, this seems to happen only with data between one and two mbuffs in size, ie. 101-207 bytes or so. Smaller and it fits in one packet, between 208 and the MTU it is properly sent in one packet. On Sat, 10 Jan 1998, Marc Slemko wrote: > Note the below tcpdump: > > 21:05:47.748479 valis.worldgate.com.1034 > testbed.worldgate.com.http: S 761734757:761734757(0) win 16384 (DF) > 21:05:47.748749 testbed.worldgate.com.http > valis.worldgate.com.1034: S 1887037484:1887037484(0) ack 761734758 win 17520 (DF) > 21:05:47.749793 valis.worldgate.com.1034 > testbed.worldgate.com.http: . ack 1 win 17520 (DF) > 21:05:47.749809 valis.worldgate.com.1034 > testbed.worldgate.com.http: P 1:101(100) ack 1 win 17520 (DF) > 21:05:47.749823 valis.worldgate.com.1034 > testbed.worldgate.com.http: FP 101:139(38) ack 1 win 17520 (DF) > 21:05:47.749837 testbed.worldgate.com.http > valis.worldgate.com.1034: . ack 140 win 17482 (DF) > 21:05:47.752540 testbed.worldgate.com.http > valis.worldgate.com.1034: F 1:1(0) ack 140 win 17520 (DF) > 21:05:47.766014 valis.worldgate.com.1034 > testbed.worldgate.com.http: . ack 2 win 17520 (DF) > > valis is a FreeBSD 2.2 box. The same thing happens on boxes from 2.1.5 to > 2.2.5. Don't have a -current box to try it... > > The connection was generated by the below program. Note that it is > a single write() or send() call that generates the data, yet it > is split into two packets. > > While it isn't a big deal here, I noticed this when I was using a simple > web benchmark program (ZeusBench) that doesn't disable the Nagle > algorithm. In that example, the server was delaying its ack (standard > 200ms) and the client wasn't sending the second part of the request (due > to Nagle) so you could only get 5 reqs/sec on a persistent connection, ie. > multiple sequential requests on one TCP connection. Disabling Nagle fixed > this of course. > > Why is this happening? Is it just a coincidence that 100 bytes > is the size of the data area in the first mbuf in a chain? > > Has it been fixed in -current or should I dig deeper... >