From owner-freebsd-current@FreeBSD.ORG Sat Nov 10 18:27:27 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7153E16A418 for ; Sat, 10 Nov 2007 18:27:27 +0000 (UTC) (envelope-from gwright@antiope.com) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by mx1.freebsd.org (Postfix) with ESMTP id 1684713C48E for ; Sat, 10 Nov 2007 18:27:26 +0000 (UTC) (envelope-from gwright@antiope.com) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA07.westchester.pa.mail.comcast.net with smtp id B0Xh1Y0051HzFnQ000Sp00; Sat, 10 Nov 2007 18:27:07 +0000 Received: from [192.168.2.42] ([72.88.201.27]) by OMTA14.westchester.pa.mail.comcast.net with comcast id B6T71Y0010byEVU0000000; Sat, 10 Nov 2007 18:27:08 +0000 X-Authority-Analysis: v=1.0 c=1 a=CxRhKOOJyq1tojiPpW0A:9 a=rmB0EnLhFQ_PjEPFBwsA:7 a=TKsB0chdH2nNGxQt_iBc7ZnjE94A:4 a=27vHs-B1mqoA:10 a=cB8LuYKA45AA:10 a=Y_EUdd4fNZkA:10 a=WuK_CZDBSqoA:10 In-Reply-To: <4735CE3A.7020905@freebsd.org> References: <46B41421-3112-40C6-84D9-094FA771F93E@antiope.com> <4735CE3A.7020905@freebsd.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1AE5FE54-7677-48B3-AD7E-34F2D1569EA3@antiope.com> Content-Transfer-Encoding: 7bit From: Gregory Wright Date: Sat, 10 Nov 2007 13:27:06 -0500 To: Andre Oppermann X-Mailer: Apple Mail (2.752.2) Cc: freebsd-current@freebsd.org Subject: Re: excessive TCP dulplicate acks revisted 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: Sat, 10 Nov 2007 18:27:27 -0000 On Nov 10, 2007, at 10:28 AM, Andre Oppermann wrote: > Gregory Wright wrote: >> (Note: long message) >> Hi, >> The tcp duplicate ACK attack is back. >> Last March, there was a thread on duplicate TCP acks in -CURRENT. >> I have been able to reproduce the problem on 7.0-BETA2 (amd64) >> and have some new information that might help locate the bug. >> Background: I first noticed problems with tcp connections dropping >> when Bacula was running on our backup server. The hardware was >> a dual Opteron 244, 2 GB RAM, running FreeBSD 6.2-RELEASE-p2. >> The ethernet NIC was a bge. >> We went through an extensive process to rule out hardware and cabling >> problems: the server hardware was replaced with a single Opteron 270 >> (dual core) on a Tyan S2882-D motherboard. The memory was replaced >> as well. The NICs are still bge. This machine is "hardtack". > > This may be a TSO bug in the bge hardware. Please repeat your > tests in > the original setup with TSO disabled on the bge interfaces > ("ifconfig bgeX -tso"). > Second if you've got another network card with something else than bge > please put it into the same box and run the tests as well. > > -- > Andre > Hi Andre, I turned off TSO on the bge interface and still had the low throughput. A packet log showed that there were still bursts of duplicate ACKs. Results of netperf from my PowerBook: crossroads-able> netperf -H hardtack TCP STREAM TEST from localhost (0.0.0.0) port 0 AF_INET to hardtack. 18clay.com (192.168.2.61) port 0 AF_INET Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 65536 262144 262144 10.02 28.37 crossroads-able> The Tyan S2882-D motherboard has two bge interfaces and an fxp as well. Switching to the fxp interface, I get much better throughput: crossroads-able> netperf -H hardtack TCP STREAM TEST from localhost (0.0.0.0) port 0 AF_INET to hardtack. 18clay.com (192.168.2.61) port 0 AF_INET Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 65536 262144 262144 10.02 93.70 crossroads-able> and the packet logs show no duplicate ACKs. I will run some longer tests to the fxp interface to verify that there are no problems. Greg