From owner-freebsd-hackers Sun Dec 2 0: 5:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.huji.ac.il (cs.huji.ac.il [132.65.16.10]) by hub.freebsd.org (Postfix) with ESMTP id 9BA2A37B419 for ; Sun, 2 Dec 2001 00:05:49 -0800 (PST) Received: from pampa.cs.huji.ac.il ([132.65.80.32] ident=exim) by cs.huji.ac.il with esmtp (Exim 3.32 #1) id 16ARdB-00024x-00; Sun, 02 Dec 2001 10:05:45 +0200 Received: from localhost ([127.0.0.1] helo=pampa.cs.huji.ac.il ident=danny) by pampa.cs.huji.ac.il with esmtp (Exim 3.22 #2) id 16ARdB-000FHc-00; Sun, 02 Dec 2001 10:05:45 +0200 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Matthew Dillon Cc: Richard Sharpe , freebsd-hackers@FreeBSD.ORG Subject: Re: Patch #2 (was Re: Found the problem, w/patch (was Re: FreeBSD performing worse than Linux?)) In-Reply-To: Message from Matthew Dillon of "Sat, 01 Dec 2001 13:21:05 PST." <200112012121.fB1LL5w36881@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 02 Dec 2001 10:05:45 +0200 From: Danny Braniss Message-Id: 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 hum, do i get a speed ticket? i did some tests before applying your patches: lizard> ./tbench 1 dev .1 clients started ..............+* Throughput 6.10567 MB/sec (NB=7.63209 MB/sec 61.0567 MBit/sec) lizard> ./tbench 2 dev ..2 clients started ........................+....+** Throughput 7.71796 MB/sec (NB=9.64745 MB/sec 77.1796 MBit/sec) lizard> ./tbench 3 dev ...3 clients started .....................................+....+.+*** Throughput 9.17012 MB/sec (NB=11.4627 MB/sec 91.7012 MBit/sec) lizard> ./tbench 4 dev ....4 clients started ........................................................++++**** Throughput 10.3365 MB/sec (NB=12.9207 MB/sec 103.365 MBit/sec) lizard> ./tbench 5 dev .....5 clients started .............................................................+.......++.+.+**** * Throughput 10.5219 MB/sec (NB=13.1523 MB/sec 105.219 MBit/sec) > 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 > > Index: uipc_socket.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v > retrieving revision 1.68.2.16 > diff -u -r1.68.2.16 uipc_socket.c > --- uipc_socket.c 2001/06/14 20:46:06 1.68.2.16 > +++ uipc_socket.c 2001/12/01 21:09:13 > @@ -910,6 +910,14 @@ > !sosendallatonce(so) && !nextrecord) { > if (so->so_error || so->so_state & SS_CANTRCVMORE) > break; > + /* > + * The window might have closed to zero, make > + * sure we send an ack now that we've drained > + * the buffer or we might end up blocking until > + * the idle takes over (5 seconds). > + */ > + if (pr->pr_flags & PR_WANTRCVD && so->so_pcb) > + (*pr->pr_usrreqs->pru_rcvd)(so, flags); > error = sbwait(&so->so_rcv); > if (error) { > sbunlock(&so->so_rcv); > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message