From owner-freebsd-stable@FreeBSD.ORG Tue Dec 1 15:27:10 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 196421065694; Tue, 1 Dec 2009 15:27:10 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by mx1.freebsd.org (Postfix) with ESMTP id 8FD7E8FC16; Tue, 1 Dec 2009 15:27:09 +0000 (UTC) Received: from w2003s01.double-l.local (double-l.xs4all.nl [80.126.205.144]) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id nB1FR7ZH042715; Tue, 1 Dec 2009 16:27:08 +0100 (CET) (envelope-from Johan@double-l.nl) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 1 Dec 2009 16:27:05 +0100 Message-ID: <57200BF94E69E54880C9BB1AF714BBCBA572A3@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0? Thread-Index: AcpymiCLiTxAmqYoSzqhyJnR1Dh3OQAACWAw References: <1259583785.00188644.1259572202@10.7.7.3> <4B153341.3060909@FreeBSD.org> From: "Johan Hendriks" To: "Alexander Motin" X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-stable@FreeBSD.org Subject: RE: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 15:27:10 -0000 >O. Hartmann wrote: >> I'm just wondering what's wrong with FreeBSD 8.0/amd64 when I read the >> Benchmarks on Phoronix.org's website. Especially FreeBSD's threaded I/O >> shows in contrast to all claims that have been to be improoved the >> opposite. >Instead of trying to compare something, I propose to look on that >numbers itself first: >- first test tells that average write latency is about 100us. But it >looks quite surprising for Laptop HDD, which has seek time of at least >several milliseconds. >- second test - a bit closer to life - 2-3ms - ok, Linux won here >slightly, as FreeBSD installation in this test had no NCQ support. >- third test - 9us per write on Linux. I am just crying. >- forth test - all OSes gave 50-80us. Probably it is just a buffer case >read time. >So most of shown cases are testing almost only file system cache >parameters. It is just insane to compare them for so different systems >with so different write-back policies. >If somebody still have questions, after some UFS parameters tuning I've >got with the same tiotest tool: >- Random Write latency - 15us, >- Random Read latency - 7us. What kind of UFS parameter tunings. >So who can beat my FreeBSD? :))) >What's about second test. To check possible NCQ effect I've built test >setup with new 320GB 7200RPM Seagate drive connected to Intel ICH10R >controller. I've run IMHO more reasonable benchmark/raidtest tool from >ports on whole device, to execute pregenerated random mix of 10000 >random-sized (512B - 128KB) read/write requests using default ata(4) >driver and new ahci(4): >Number of READ requests: 5029. >Number of WRITE requests: 4971. >Number of bytes to transmit: 655986688. >Number of processes: 32. >The results: >ata(4) - no NCQ: >Bytes per second: 12455402 >Requests per second: 189 >ahci(4) - with NCQ: >Bytes per second: 19889778 >Requests per second: 303 >Results are repeatable up to the 4-th digit. Average time per request is >5.29ms and 3.3ms respectively, that is realistic for this drive. >So, with such difference, I believe, we will not loose this test any more. >--=20 >Alexander Motin If things ar tuned for old hardware, which hardware are we talking about i386? Or i486? Maybe we should set the defaults for AMD64 in a way that modern hardware can handle. AMD64 is a for modern hardware, it does not run on a pentium3. Regards, Johan Hendriks =20