Date: Tue, 13 Jan 1998 05:34:37 +0100 (MET) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: hackers@FreeBSD.ORG Subject: Re: delayed ACKs (fwd) Message-ID: <199801130434.FAA14829@labinfo.iet.unipi.it>
next in thread | raw e-mail | index | archive | help
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 <marcs@znep.com> > To: Alan Cox <alan@lxorguk.ukuu.org.uk> > 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/ _____________________________|______________________________________
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801130434.FAA14829>