Date: Sun, 11 Jan 1998 16:33:15 -0700 (MST) From: Marc Slemko <marcs@znep.com> To: Snob Art Genre <benedict@echonyc.com> Cc: hackers@FreeBSD.ORG Subject: Re: why 100 byte TCP segments? Message-ID: <Pine.BSF.3.95.980111162702.10734e-100000@alive.znep.com> In-Reply-To: <Pine.GSO.3.96.980111182400.333C-100000@echonyc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Aha. Yes, section 14.11. He suggests either knocking MINCLSIZE down to 101, increasing the size of a mbuf from 128 to 256 bytes, or changing sosend to avoid sending multiple packets when mbufs (instead of mbuf clusters) are being used. The last one may be a better solution, but the first is easier. I can't see much in the way of bad side effects offhand to changing MINCLSIZE... certainly not compared to how annoying this is. It sucks when it triggers slow start or Nagle especially with delayed acks. On Sun, 11 Jan 1998, Snob Art Genre wrote: > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.980111162702.10734e-100000>