From owner-freebsd-hackers Sat Dec 1 13:38:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id C1C1937B405 for ; Sat, 1 Dec 2001 13:38:16 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB1LcG837063; Sat, 1 Dec 2001 13:38:16 -0800 (PST) (envelope-from dillon) Date: Sat, 1 Dec 2001 13:38:16 -0800 (PST) From: Matthew Dillon Message-Id: <200112012138.fB1LcG837063@apollo.backplane.com> To: Richard Sharpe , freebsd-hackers@FreeBSD.ORG Subject: Re: Patch #2 (was Re: Found the problem, w/patch (was Re: FreeBSD performing worse than Linux?)) References: <20011128153817.T61580@monorchid.lemis.com> <15364.38174.938500.946169@caddis.yogotech.com> <20011128104629.A43642@walton.maths.tcd.ie> <5.1.0.14.1.20011130181236.00a80160@postamt1.charite.de> <200111302047.fAUKlT811090@apollo.backplane.com> <200111302130.fAULUU324648@apollo.backplane.com> <3C08CF9D.2030109@ns.aus.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Oh, I forgot to mention... there's still a bug. You have to turn off delayed acks to get the below numbers. Otherwise the window 0 recovery ack ... gets delayed. Joy. It's easy to fix, but I'm off to see Potter so it will be tonight. -Matt : Richard (and others), please try this patch. With this patch I : get the following between two machines connected via a 100BaseTX : switch (full duplex): : : ---------------- : : test1:/home/dillon/dbench> ./tbench 1 test2 : .1 clients started : ..............+* : Throughput 6.13925 MB/sec (NB=7.67406 MB/sec 61.3925 MBit/sec) 1 procs : test1:/home/dillon/dbench> ./tbench 2 test2 : ..2 clients started : ............................++** : Throughput 8.37795 MB/sec (NB=10.4724 MB/sec 83.7795 MBit/sec) 2 procs : : ---------------- : : On localhost I get: : : ---------------- : : test1:/home/dillon/dbench> ./tbench 1 localhost : .1 clients started : ..............+* : Throughput 25.7156 MB/sec (NB=32.1445 MB/sec 257.156 MBit/sec) 1 procs : test1:/home/dillon/dbench> ./tbench 2 localhost : ..2 clients started : ............................++** : Throughput 36.5428 MB/sec (NB=45.6785 MB/sec 365.428 MBit/sec) 2 procs : test1:/home/dillon/dbench> : : ---------------- : : This is WITHOUT changing the default send and receive tcp buffers.. : they're both 16384. : : The bug I found is that when recv() is used with MSG_WAITALL, : which is what tbench does, soreceive() will block waiting for all : available input WITHOUT ever calling pr->pr_usrreqs->pru_rcvd(), : which means that if the sender filled up the receive buffer (16K default) : the receiver will never ack the 0 window... that is until the idle code : takes over after 5 seconds. : : -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message