Re: excessive TCP duplicate acks?

On Jan 26, 2007, at 11:59 AM, Andrew Gallatin wrote:

When running some benchmarks, I noticed tons of duplicate acks showing
up in systat -tcp (thousands, or tens of thousands per second).
Taking a trace, I see that -current seems to send "lots" of duplicate
acks. At first I thought this was a driver bug, but I've seen it with
3 different drivers (mxge, nve, xl) and at various network speeds. It
seems to happen when the -current machine is the "sender" in a
netperf, and seems to happen with both a linux a FreeBSD receiver,
and is easy to reproduce using -current from yesterday (running
on amd64 if it matters).

From my very naive tcpdump reading skills, it looks like the FreeBSD
machine sends a full window with a partial payload and a push flag in
the last segment. It ignores (or does not yet see the receiver's
acks). It then spews tons of duplicate acks at the reciever until it
notices the acks, and starts sending data again. This happens over
and over again..

Is this normal, or is there something wrong?

In the appended tcpdump snippet taken at the receiver, 172.31.193.16
was sending a netperf (netperf -H172.31.193.15 -- -s65535 -S32767) to
172.31.193.15. I can make a raw dump file available if anybody
is interested.

<..many packets omitted..>

I saw this behavior on an Intel gigabit NIC (em driver) with a kernel from January 22nd. This problem still persists with a kernel from today. Enabling/Disabling tx/rxcsum doesn't help.

Machine details can be found up at http://bling.properkernel.com/ freebsd/ (Which is incidentally the machine that is seeing these issues). If you would like to see just what kind of traffic patterns I am seeing, load up wireshark / tcpdump and download one of the freebsd release images on the webserver.

uname -a: FreeBSD bling.properkernel.com 7.0-CURRENT FreeBSD 7.0- CURRENT #8: Mon Feb 19 16:21:52 EST 2007 andy@xxxxxxxxxxxxxxxxxxxxxx:/usr/obj/usr/src/sys/BLING i386

Andy

/* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */
/* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */
/* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */
/* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */

_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: read() returns ETIMEDOUT on steady TCP connection
    ... It's relatively simple at its core -- readfrom an inbound connection and writeto outbound sockets. ... I've traced the source of the ETIMEDOUT within the kernel to ... but it seems to implies that it's reaching a limit of a number of retransmits of sending ACKs on the TCP connection receiving the inbound data? ... With ACKs in mind, I took the test back to stock kernel and configuration, and went ahead with disabling sack on the server and the client which supplies the data. ...
    (freebsd-net)
  • Re: excessive TCP duplicate acks?
    ... the last segment. ... It then spews tons of duplicate acks at the reciever until it ... I will see if a kernel from today fixes the issue or if checksum offloading is to blame, later tonight when I run a series of tests. ...
    (freebsd-current)