Date: Fri, 30 Nov 2001 15:08:43 -0600 From: Alfred Perlstein <bright@mu.org> To: rsharpe@ns.aus.com Cc: Matthew Dillon <dillon@apollo.backplane.com>, Alexander Haderer <alexander.haderer@charite.de>, freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD performing worse than Linux? Message-ID: <20011130150843.L46769@elvis.mu.org> In-Reply-To: <3C07FCFF.4070008@ns.aus.com>; from sharpe@ns.aus.com on Sat, Dec 01, 2001 at 08:11:19AM %2B1030 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> <3C07FCFF.4070008@ns.aus.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Richard Sharpe <sharpe@ns.aus.com> [011130 15:02] wrote:
> Matthew Dillon wrote:
>
> > Well, this is embarassing. I can reproduce this completely running
> > 4.4-stable (Nov 17th kernel) on two machines.
> >
> > With newreno turned on, a TCP NFS mount only gets 80K/sec. With newreno
> > turned off on the transmit side, a TCP NFS mount gets 7MB/sec. The
> > state of the delayed-ack sysctl is irrelevant. This is without running
> > any nfsiod's (which would mask the degredation of the synchronous
> > messaging).
>
>
> I have upgraded to 4.4-STABLE, and have hacked in some changes to ata-dma.c (provided by Greg Lehey, but I had to do it by hand) so my drive is now running at UDMA 100.
>
>
> I have also ensured that disk write caching is on, which it seems to be
> by default in 4.4.
>
> These changes have made a difference to the NetBench and dbench runs (improved them), but they have made no difference to the tbench runs, which only do network stuff.
>
>
> The traffic in the tbench case is SMB taffic. Request/response, with a mixture of small requests and responses, and big request/small response or small request/big response, where big is 64K.
>
>
> I have switched off newreno, and it made no difference. I have switched
> off delayed_ack, and it reduced performance about 5 percent. I have made
> sure that SO_SNDBUF and SO_RCVBUF were set to 131072 (which seems to be
> the max), and it increased performance marginally (like about 2%), but
> consistently.
>
> I am still analysing the packet traces I have, but it seems to me that
> the crucial difference is Linux seems to delay longer before sending
> ACKs, and thus sends less ACKs. Since the ACK is piggybacked in the
> response (or the next request), it all works fine, and the
> reponse/request gets there sooner.
>
> However, I have not convinced myself that the saving of 20uS or so per
> request/response pair accounts for some 40+ Mb/s.
Can you try these two commands:
sysctl -w net.inet.tcp.recvspace=65536
sysctl -w net.inet.tcp.sendspace=65536
you can put them in /etc/sysctl.conf as:
net.inet.tcp.recvspace=65536
net.inet.tcp.sendspace=65536
thanks,
--
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
http://www.morons.org/rants/gpl-harmful.php3
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011130150843.L46769>