On 27 Nov 2008, at 14:03, David Malone wrote:
I was looking at some tcpdumps from a FreeBSD box receiving a TCP
stream with someone yesterday and noticed that it seemed to be
generating quite a lot of dupliacte acks. Looking more carefully,
we noticed that the duplicates were actually window updates. The
code for sending window updates can be found in:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_output.c?annot
ate=1.157
around lines 541-565. It seems that we generate a window update if
the available buffer space changes by more than two packets, or if
it changes by more than half the buffer size. This is probably a
little aggressive, and in some cases seems to result in bursts of
window updates that look like they should be batched. I wonder if
it would make sense to not do a window update if a delayed ack is
scheduled? It might even be possible to do them as a delayed ack
without causing problems.
Yes, this makes sense. Probably this is a bug since 4.4BSD-Lite.
I note that there is at least one PR mentioning we generate many
window updates:
http://www.freebsd.org/cgi/query-pr.cgi?pr=116335
I also wonder if it might cause non-FreeBSD senders to back off,
we are careful not to retransmit if we get window updates (see
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c?annota
te=1.392
about line 1836, but other OSes might not be and that might degrade
our performance when receiving from a non-FreeBSD sender.
So, from what I understand, we do back off and that implies we are
losing performance in the FreeBSD to FreeBSD case, right?
--
Rui Paulo
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
