From owner-freebsd-current@FreeBSD.ORG Fri Jan 26 16:59:12 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 8DF7E16A400 for ; Fri, 26 Jan 2007 16:59:12 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 5EAE013C489 for ; Fri, 26 Jan 2007 16:59:12 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.6/8.13.6) with ESMTP id l0QGxBXa014532 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 26 Jan 2007 11:59:11 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id l0QGx6HD015009; Fri, 26 Jan 2007 11:59:06 -0500 (EST) (envelope-from gallatin) From: Andrew Gallatin Message-ID: <17850.13146.266196.499166@grasshopper.cs.duke.edu> Date: Fri, 26 Jan 2007 11:59:06 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: freebsd-current@freebsd.org X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Subject: 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: Fri, 26 Jan 2007 16:59:12 -0000 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. Thanks, Drew 11:14:13.524661 IP 172.31.193.16.65344 > 172.31.193.15.32809: S 1455368652:1455368652(0) win 65535 11:14:13.524668 IP 172.31.193.15.32809 > 172.31.193.16.65344: S 3829892109:3829892109(0) ack 1455368653 win 5792 11:14:13.524727 IP 172.31.193.16.65344 > 172.31.193.15.32809: . ack 1 win 65535 11:14:13.525051 IP 172.31.193.16.65344 > 172.31.193.15.32809: . 1:1449(1448) ack 1 win 65535 11:14:13.525061 IP 172.31.193.15.32809 > 172.31.193.16.65344: . ack 1449 win 17 11:14:13.525174 IP 172.31.193.16.65344 > 172.31.193.15.32809: . 1449:2897(1448) ack 1 win 65535 <..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