From owner-freebsd-current@FreeBSD.ORG Mon Feb 19 22:55:28 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7536116EBE2 for ; Mon, 19 Feb 2007 22:55:28 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.freebsd.org (Postfix) with ESMTP id 2D47D13C474 for ; Mon, 19 Feb 2007 22:55:27 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from [10.7.6.254] ([63.76.235.163]) by lexi.siliconlandmark.com (8.13.8/8.13.3) with ESMTP id l1JMhswQ085889 for ; Mon, 19 Feb 2007 17:44:04 -0500 (EST) (envelope-from andy@siliconlandmark.com) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <17850.13146.266196.499166@grasshopper.cs.duke.edu> References: <17850.13146.266196.499166@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7BA0B599-82E7-4228-8E96-EF3D9531C566@siliconlandmark.com> Content-Transfer-Encoding: 7bit From: Andre Guibert de Bruet Date: Mon, 19 Feb 2007 17:43:48 -0500 To: freebsd-current X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV 0.88.7/2607/Mon Feb 19 12:56:34 2007 on lexi.siliconlandmark.com X-Virus-Status: Clean X-Information: Please contact the ISP for more information X-SL-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-SL-SpamCheck: not spam, SpamAssassin (not cached, score=-1.395, required 6, AWL 0.06, BAYES_00 -2.60, SPF_FAIL 1.14) X-MailScanner-From: andy@siliconlandmark.com Subject: Re: excessive TCP duplicate acks? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 22:55:28 -0000 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 > 11:14:13.530467 IP 172.31.193.16.65344 > 172.31.193.15.32809: . > 63713:65161(1448) ack 1 win 65535 > 11:14:13.530474 IP 172.31.193.15.32809 > 172.31.193.16.65344: . ack > 65161 win 94 > 11:14:13.530504 IP 172.31.193.16.65344 > 172.31.193.15.32809: P > 65161:65536(375) ack 1 win 65535 > 11:14:13.530511 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack > 1 win 65535 > 11:14:13.530516 IP 172.31.193.15.32809 > 172.31.193.16.65344: . ack > 65536 win 94 > 11:14:13.530518 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack > 1 win 65535 > 11:14:13.530525 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack > 1 win 65535 > 11:14:13.530533 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack > 1 win 65535 > 11:14:13.530540 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack > 1 win 65535 > 11:14:13.530547 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack > 1 win 65535 > 11:14:13.530554 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack > 1 win 65535 > 11:14:13.530561 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack > 1 win 65535 > 11:14:13.530569 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack > 1 win 65535 > 11:14:13.530576 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack > 1 win 65535 > 11:14:13.530584 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack > 1 win 65535 > 11:14:13.530591 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack > 1 win 65535 > 11:14:13.530597 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack > 1 win 65535 > 11:14:13.530604 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack > 1 win 65535 > 11:14:13.530612 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack > 1 win 65535 > 11:14:13.530619 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack > 1 win 65535 > 11:14:13.530752 IP 172.31.193.16.65344 > 172.31.193.15.32809: . > 65536:66865(1329) ack 1 win 65535 > 11:14:13.530760 IP 172.31.193.15.32809 > 172.31.193.16.65344: . ack > 66865 win 94 > 11:14:13.530884 IP 172.31.193.16.65344 > 172.31.193.15.32809: . > 66865:68313(1448) ack 1 win 65535 > 11:14:13.531007 IP 172.31.193.16.65344 > 172.31.193.15.32809: . > 68313:69761(1448) ack 1 win 65535 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 */