From owner-freebsd-net Tue Oct 12 11: 9: 3 1999 Delivered-To: freebsd-net@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 33A90152DF for ; Tue, 12 Oct 1999 11:09:00 -0700 (PDT) (envelope-from aron@cs.rice.edu) Received: (from aron@localhost) by cs.rice.edu (8.9.0/8.9.0) id NAA19953; Tue, 12 Oct 1999 13:08:52 -0500 (CDT) From: Mohit Aron Message-Id: <199910121808.NAA19953@cs.rice.edu> Subject: Re: delayed ACKs To: m8jaci@etek.chalmers.se, freebsd-net@freebsd.org Date: Tue, 12 Oct 1999 13:08:51 -0500 (CDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > According to what I have studied, delayed ACKs can be sent: > (1)every 200 ms > (2)when I have data to send (piggyback packet) > (3)every second packet > so I don't understand why in the example below, there are ACKs that > acknowledge up to 7 segments. (in the example I have just sent 50 > segments of 1460 bytes from the client to the server) Yes, I've seen that. An ACK is sent when the receiver process actually picks up the data from the socket buffers. Now it is possible that the time taken between: pkt reception -> pkt processing -> receiving process getting scheduled -> receiving process reading data from socket is greater than the packet inter-arrival time. This does indeed happen on high b/w networks and since pkt processing is given higher priority, you'll often see ACKs acknowledging large number of packets. Check out the section on "big ACKs" in the appendix of the paper that I recently posted on this list - its available from http://www.cs.rice.edu/~aron/papers/soft-timers.ps.gz. - Mohit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message