From owner-freebsd-hackers Tue Jan 13 19:00:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA25987 for hackers-outgoing; Tue, 13 Jan 1998 19:00:50 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id RAA18284 for ; Tue, 13 Jan 1998 17:57:53 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id FAA14829 for hackers@freebsd.org; Tue, 13 Jan 1998 05:34:37 +0100 From: Luigi Rizzo Message-Id: <199801130434.FAA14829@labinfo.iet.unipi.it> Subject: Re: delayed ACKs (fwd) To: hackers@FreeBSD.ORG Date: Tue, 13 Jan 1998 05:34:37 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk I found this on the tcp-impl list... can someone comment if the feature is still there in -current (or it ever was) ? Cheers Luigi Forwarded message: > From owner-tcp-impl@cthulhu.engr.sgi.com Mon Jan 12 23:15:03 1998 > Date: Mon, 12 Jan 1998 16:06:35 -0700 (MST) > From: Marc Slemko > To: Alan Cox > cc: tcp-impl@cthulhu.engr.sgi.com > Subject: Re: delayed ACKs > Sender: owner-tcp-impl@cthulhu.engr.sgi.com > > On Mon, 12 Jan 1998, Alan Cox wrote: > > > > The case where the interaction between Nagle and delayed ACKs > > > becomes a problem is when the receiver can't do anything until > > > it gets the data that hasn't been sent yet, defered by the Nagle > > > algorithm. The Nagle code is waiting for the ACK, and there is > > > no return data on which to piggy-back the delayed ACK, so you > > > wait for the delayed ACK timer to go off. > > > > However 4.4 BSD explicitly checks and does not delay an ack for a > > smaller than MTU sized frame. So this appears less of a problem anyway > > if Im reading my copy of Stevens right > > I don't know exactly what you are looking at, but unless I am missing > something, it doesn't behave that way for me... > > In fact, just the other day, I ran into a cute problem doing some simple > web server benchmarking. I was getting 5 requests/sec. That number alone > made me suspicious; 200ms*5 = 1s. > > What was happening is a BSD bug (cf. TCP/IP Ill vol3, section 14.11) was > causing the client (FreeBSD 2.2) to put a write() of between.. erm... 101 > and 208 bytes into two mbufs instead of a mbuf cluster. This means it was > sent in two packets. Slow start wasn't the issue since I was using > persistent connections, but Nagle on the client combined with delayed ack > from the server was causing the client to delay sending the second packet > in the request until the ack arrived for the first packet, 200ms later. > Hence almost exactly 5 requests/sec. > > The server was also FreeBSD 2.2; unless something has changed from 4.4BSD > there, it does delay acks for frames smaller than the MTU. > > I guess I can be thankful that most HTTP requests are more bloated than > 208 bytes or the client could disable Nagle to work around it. Slow-start > still could pose a problem though. -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________