Date: Sun, 11 Jan 1998 18:25:28 -0500 (EST) From: Snob Art Genre <benedict@echonyc.com> To: Marc Slemko <marcs@znep.com> Cc: hackers@FreeBSD.ORG Subject: Re: why 100 byte TCP segments? Message-ID: <Pine.GSO.3.96.980111182400.333C-100000@echonyc.com> In-Reply-To: <Pine.BSF.3.95.980111153144.10734d-100000@alive.znep.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Oh yeah, doesn't Stevens talk about this in TCP/IP Illustrated Vol. 3? It's a particularly obnoxious problem because HTTP traffic so often falls into the bad range. Does anyone have any ideas/motivation to fix this, or should I start researching it myself? :-) On Sun, 11 Jan 1998, Marc Slemko wrote: > 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... > > > > Ben "You have your mind on computers, it seems."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.3.96.980111182400.333C-100000>