Re: excessive TCP duplicate acks?

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

>> 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..>
>
> 11:14:13.530344 IP 172.31.193.16.65344 > 172.31.193.15.32809: .  
> 62265:63713(1448) ack 1 win 65535 <nop,nop,timestamp 262294 1314603>
> 11:14:13.530467 IP 172.31.193.16.65344 > 172.31.193.15.32809: .  
> 63713:65161(1448) ack 1 win 65535 <nop,nop,timestamp 262294 1314603>
> 11:14:13.530474 IP 172.31.193.15.32809 > 172.31.193.16.65344: . ack  
> 65161 win 94 <nop,nop,timestamp 1314604 262294>
> 11:14:13.530504 IP 172.31.193.16.65344 > 172.31.193.15.32809: P  
> 65161:65536(375) ack 1 win 65535 <nop,nop,timestamp 262294 1314603>
> 11:14:13.530511 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack  
> 1 win 65535 <nop,nop,timestamp 262294 1314603>
> 11:14:13.530516 IP 172.31.193.15.32809 > 172.31.193.16.65344: . ack  
> 65536 win 94 <nop,nop,timestamp 1314604 262294>
> 11:14:13.530518 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack  
> 1 win 65535 <nop,nop,timestamp 262294 1314603>
> 11:14:13.530525 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack  
> 1 win 65535 <nop,nop,timestamp 262294 1314603>
> 11:14:13.530533 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack  
> 1 win 65535 <nop,nop,timestamp 262294 1314603>
> 11:14:13.530540 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack  
> 1 win 65535 <nop,nop,timestamp 262294 1314603>
> 11:14:13.530547 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack  
> 1 win 65535 <nop,nop,timestamp 262294 1314603>
> 11:14:13.530554 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack  
> 1 win 65535 <nop,nop,timestamp 262294 1314603>
> 11:14:13.530561 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack  
> 1 win 65535 <nop,nop,timestamp 262294 1314603>
> 11:14:13.530569 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack  
> 1 win 65535 <nop,nop,timestamp 262294 1314603>
> 11:14:13.530576 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack  
> 1 win 65535 <nop,nop,timestamp 262294 1314603>
> 11:14:13.530584 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack  
> 1 win 65535 <nop,nop,timestamp 262294 1314603>
> 11:14:13.530591 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack  
> 1 win 65535 <nop,nop,timestamp 262294 1314603>
> 11:14:13.530597 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack  
> 1 win 65535 <nop,nop,timestamp 262294 1314603>
> 11:14:13.530604 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack  
> 1 win 65535 <nop,nop,timestamp 262294 1314603>
> 11:14:13.530612 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack  
> 1 win 65535 <nop,nop,timestamp 262294 1314603>
> 11:14:13.530619 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack  
> 1 win 65535 <nop,nop,timestamp 262294 1314603>
> 11:14:13.530752 IP 172.31.193.16.65344 > 172.31.193.15.32809: .  
> 65536:66865(1329) ack 1 win 65535 <nop,nop,timestamp 262294 1314603>
> 11:14:13.530760 IP 172.31.193.15.32809 > 172.31.193.16.65344: . ack  
> 66865 win 94 <nop,nop,timestamp 1314604 262294>
> 11:14:13.530884 IP 172.31.193.16.65344 > 172.31.193.15.32809: .  
> 66865:68313(1448) ack 1 win 65535 <nop,nop,timestamp 262294 1314603>
> 11:14:13.531007 IP 172.31.193.16.65344 > 172.31.193.15.32809: .  
> 68313:69761(1448) ack 1 win 65535 <nop,nop,timestamp 262294 1314603>

I am seeing similar problems on an Intel gigabit NIC (em driver) with  
a kernel from January 22nd. I have rx and tx checksum offloading  
enabled. 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.

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 */