Date: Sun, 11 Jan 1998 15:34:50 -0700 (MST) From: Marc Slemko <marcs@znep.com> To: hackers@FreeBSD.ORG Subject: Re: why 100 byte TCP segments? Message-ID: <Pine.BSF.3.95.980111153144.10734d-100000@alive.znep.com> In-Reply-To: <Pine.BSF.3.95.980110210531.3955C-100000@alive.znep.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <mss 1460> (DF) > 21:05:47.748749 testbed.worldgate.com.http > valis.worldgate.com.1034: S 1887037484:1887037484(0) ack 761734758 win 17520 <mss 1460> (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... >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.980111153144.10734d-100000>