Date: Sat, 1 Dec 2001 14:07:41 +1030 From: Greg Lehey <grog@FreeBSD.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: <20011201140741.J611@monorchid.lemis.com> In-Reply-To: <3C07FCFF.4070008@ns.aus.com> 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
On Saturday, 1 December 2001 at 8:11:19 +1030, Richard Sharpe 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) What did you have to do by hand? > so my drive is now running at UDMA 100. Can you send me dmesg output? In particular, I had a printf output there to show what the BIOS had set. Background for other people: Richard has an IDE chip which claims to be a SiS 5591, which according to the data sheet can't do better than UDMA 33. When he runs Linux on the box, however, it claims to be running at UDMA 100, and this hack seems to have had the same effect. > I have also ensured that disk write caching is on, which it seems to > be by default in 4.4. Yes, I think this is correct. > 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. I'd like to see the new dbench results. > 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. Have you tried Matt Dillon's patch? > 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. As long as the ack traffic isn't saturating the link, and you're not running half-duplex, I can't see how that would be the problem. Greg -- See complete headers for address and phone numbers 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?20011201140741.J611>