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. oh
On Nov 30, 2009, at 9:47 AM, 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.Corrected link: http://www.phoronix.com/scan.php?page=article&item=freebsd8_benchmarks&num=1 And yeah, quite honestly: disk scheduling in FreeBSD appears to suck... The only reason I'm not switching from Linux. :( Regards, Thomas (PS. See my thread about horrible console latency during disk IO in the archives, very related. DS.)
In response to Ivan Voras <ivoras@freebsd.org>:> Thomas Backman wrote: > > On Nov 30, 2009, at 9:47 AM, 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. > > Corrected link: http://www.phoronix.com/scan.php?page=article&item=freebsd8_benchmarks&num=1 > > > > And yeah, quite honestly: disk scheduling in FreeBSD appears to suck... The only reason I'm not switching from Linux. :("All operating systems were left with their default options during the installation process..." It's common knowledge that the default value for vfs.read_max is non- optimal for most hardware and that significant performance improvements can be made in most cases by raising it. While it would be nice if FreeBSD shipped with a more performant default setting, it would also be nice if mindless benchmark drones would quit assuming that every system ships pre-configured to perform optimally in their benchmarks. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/
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. > > ohThis all reminds me of a few releases ago MySQL performance being terrible. I guess this is still the same? We've had arguments internally weather certain machines are FreeBSD like some existing or Linux like other existing as Linux always out-performed by miles. We never tested these using on OpenBSD however, so I don't know if that had the same problem...
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. 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. -- Alexander Motin