Date: Wed, 24 Jan 2001 15:32:09 -0500 (EST) From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> To: Paul Herman <pherman@frenchfries.net> Cc: <net@FreeBSD.ORG> Subject: Re: I have delayed ACK problems Message-ID: <200101242032.PAA63576@khavrinen.lcs.mit.edu> In-Reply-To: <Pine.BSF.4.32.0101241854420.21262-100000@husten.security.at12.de> References: <200101241721.f0OHL2627523@prism.flugsvamp.com> <Pine.BSF.4.32.0101241854420.21262-100000@husten.security.at12.de>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Wed, 24 Jan 2001 20:50:06 +0100 (CET), Paul Herman <pherman@frenchfries.net> said: > Something just doesn't sit well me. This shouldn't happen in a > 100Mbit LAN. This seems like a plain vanilla network transaction, and > FreeBSD is failing on something, where other OSes in the same > environment don't. Is your Solaris server attempting to do tinygram avoidance and getting it wrong? (There are some modes in which tinygram avoidance and delayed acks can combine to degrade TCP to lock-step mode. FreeBSD used to have a kluge to work around this.) That's the only think I can think of that would cause the sender-TCP to wait for an ack at the point demonstrated in your trace. Interactive protocols like X defeat tinygram avoidance by turning on TCP_NODELAY, but you'll probably have a hard time getting the Orrible server to do that. The first ACK gets sent quickly because your client application is blocked in read(); when the first data packet comes in, the application is awakened. The first four data packets arrive back-to-back, so the user process doesn't get scheduled until after the fourth. When that happens, it's already in the kernel (blocked in read() as I said) and immediately sucks all of the data out of the socket buffer. This causes the receive window to be updated, which forces the acknowledgement out immediately. For whatever reason, the next two packets are not being read immediately. Perhaps the client is off doing something else, or isn't getting scheduled, or perhaps it has set its wakeup threshold (SO_RCVLOWAT) too high. In any event, nothing takes place on the client side which would cause it to send an immediate ack, so nothing happens until the delayed-ack timer fires. This causes the other end to wake up and start sending again. In 4.3-Net/2 (FreeBSD 1.x) we had code in the header-prediction fast path which would automatically defeat delayed-ack when receiving short packets. (I don't have the 1.x CVS repository available here so I don't know whether this was introduced by David or came as a part of Net/2.) ISTR a recommendation from somewhere that TCP should ack no fewer than 1/2 of all received data segments. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101242032.PAA63576>