Date: Fri, 11 Mar 2005 20:20:02 +0900 (JST) From: Noritoshi Demizu <demizu@dd.iij4u.or.jp> To: freebsd-net@freebsd.org Subject: Re: FreeBSD 4.x and OS-X tcp performance Message-ID: <20050311.202002.26516944.Noritoshi@Demizu.ORG> In-Reply-To: <200503081411.j28EB0Hv001184@casselton.net> References: <20050308101633.GC26999@insomnia.benzedrine.cx> <200503081411.j28EB0Hv001184@casselton.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> The server is not telling the client that a packet has been lost.
> The first two ACKs are correct duplicate ACKs, but the remaining
> ACKs coming from he server have window adjustments, so the
> client does not treat them as duplicate ACKs coming from a packet
> loss.
I made a list of ACKs with ack=4195629532. I added differences with
their previous window sizes in parenthesises for each line. (See below)
I guess if the difference < 2 * 1448, it would be an ACK sent in reply
to an out-of-order data segment (i.e., it really is a dup ACK).
Otherwise, it would be a pure window update. I added my guess for each
line below. There are 12 dup ACKs, which is equal to the number of data
segment beyond the lost packet. And there are 12 window updates.
ack 4195629532 win 5792 (-) <- Original ACK
ack 4195629532 win 6576 (+784) <- dup ACK (with window update)
ack 4195629532 win 6576 (0) <- dup ACK
ack 4195629532 win 7240 (+664) <- dup ACK (with window update)
ack 4195629532 win 10672 (+3432) <- window update
ack 4195629532 win 12720 (+2048) <- dup ACK (with window update)
ack 4195629532 win 14768 (+2048) <- dup ACK (with window update)
ack 4195629532 win 14768 (0) <- dup ACK
ack 4195629532 win 16816 (+2048) <- dup ACK (with window update)
ack 4195629532 win 18864 (+2048) <- dup ACK (with window update)
ack 4195629532 win 18864 (0) <- dup ACK
ack 4195629532 win 20912 (+2048) <- dup ACK (with window update)
ack 4195629532 win 22960 (+2048) <- dup ACK (with window update)
ack 4195629532 win 22960 (0) <- dup ACK
ack 4195629532 win 26032 (+3072) <- window update
ack 4195629532 win 29104 (+3072) <- window update
ack 4195629532 win 32176 (+3072) <- window update
ack 4195629532 win 35248 (+3072) <- window update
ack 4195629532 win 38320 (+3072) <- window update
ack 4195629532 win 41392 (+3072) <- window update
ack 4195629532 win 44464 (+3072) <- window update
ack 4195629532 win 47536 (+3072) <- window update
ack 4195629532 win 50608 (+3072) <- window update
ack 4195629532 win 53680 (+3072) <- window update
ack 4195629532 win 56752 (+3072) <- window update
There are four dup ACKs whose window field is the same as its previous
ACK. If the sender counted them as dup ACKs, the sender was able to do
FastRetransmit. But the sender did not. The reason would be that the
sender might clear t_dupacks when receiving a window update.
In FreeBSD current, line 1909 of tcp_input.c rev 1.268 does this.
I am not sure it is a correct procedure.
By the way, the receiver application seems to call read() with bufsize=1024.
If the bufsize was larger than or equal to 2 * 1448, e.g., 4096, window
updates would be sent independently from dup ACKs. Since the number of
dup ACKs would be increased, the chance the receiver sends consecutive
three dup ACKs might be increaced.
Or if the receiver machine was replaced with a faster machine, the
receiver application ran faster and the receive buffer would be always
almost empty. In this case, the number of window updates would be
decreased and the chance the receiver sends consecutive three dup ACKs
would be increaced.
These may improve the TCP performance in this particular case.
Regards,
Noritoshi Demizu
ps. In tcpdump.osx-fbsd, I saw six retransmission timeouts.
Retransmission timeout values are from 1 second to 1.5 seconds.
They occupies almost all the total time of the transfer (8.6 seconds).
Outstanding window seems less than 10 MSS, and in most cases, it is
less than 6 MSS due to advertized window size. So, if Fast Retransmit
worked, the TCP performance would be drastically improved in this
particular case.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050311.202002.26516944.Noritoshi>