Date: Wed, 02 Feb 2005 17:21:11 -0500 From: Mike Tancsa <mike@sentex.net> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-performance@freebsd.org Subject: Re: FreeBSD 5.3 I/O Performance / Linux 2.6.10 and dragonfly Message-ID: <6.2.1.2.0.20050202170217.02d509e0@64.7.153.2> In-Reply-To: <200502022158.j12LwxGn002992@apollo.backplane.com> References: <20050130120437.93214.qmail@web26810.mail.ukl.yahoo.com> <6.2.1.2.0.20050201113451.0313ee20@64.7.153.2> <6.2.1.2.0.20050201193210.0489e6f8@64.7.153.2> <200502022158.j12LwxGn002992@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 04:58 PM 02/02/2005, Matthew Dillon wrote: > Urmmm. how about a bit more information... what are the machine > configurations? Sorry, it was a few postings ago in the same thread. Its Pentium(R) 4 CPU 3.00GHz 2GB RAM Intel Gig NICs (em) One big RAID5 partition on a 8xxx 3ware with 4 SATA drives, default options on the 3ware. full dmesg at http://lists.freebsd.org/pipermail/freebsd-performance/2005-February/001077.html Apart from the dragonfly boot CD, I had a separate IDE disk for the OSes that I would boot from so that the partition info for the 3ware would remain the same. [nfs]# diskinfo -tv twed0s1d twed0s1d 512 # sectorsize 750170179584 # mediasize in bytes (699G) 1465176132 # mediasize in sectors 91202 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. Seek times: Full stroke: 250 iter in 4.393885 sec = 17.576 msec Half stroke: 250 iter in 4.386907 sec = 17.548 msec Quarter stroke: 500 iter in 6.939157 sec = 13.878 msec Short forward: 400 iter in 2.234404 sec = 5.586 msec Short backward: 400 iter in 2.124618 sec = 5.312 msec Seq outer: 2048 iter in 0.360554 sec = 0.176 msec Seq inner: 2048 iter in 0.386926 sec = 0.189 msec Transfer rates: outside: 102400 kbytes in 1.443528 sec = 70937 kbytes/sec middle: 102400 kbytes in 1.399967 sec = 73145 kbytes/sec inside: 102400 kbytes in 1.428718 sec = 71673 kbytes/sec [nfs]# > I can figure some things out. Clearly the BSD write numbers are dropping > at a block size of 2048 due to vfs.write_behind being set to 1. Interesting, I didnt know of this. I really should re-read tuning(8). What are the dangers of setting it to zero? > Just as > clearly, Linux is not bothering to write out ANY data, and then able to > take advantage of the fact that the test file is being destroyed by > iozone (so it can throw away the data rather then write it out). This > skews the numbers to the point where the benchmark doesn't even come > close > to reflecting reality, though I do believe it points to an issue with > the BSDs ... the write_behind heuristic is completely out of date now > and needs to be reworked. http://www.iozone.org is what I was using to test with. Although right now, the box I am trying to put together is a Samba and NFS server for mostly static web content. In the not too distant future, a file server for IMAP/POP3 front ends. I think postmark does a good job at simulating that. Are there better benchmarks / methods of testing that would give a more fair comparison that you know of? I know all benchmarks have many caveats, but I am trying to approach this somewhat methodically. I am just about to start another round of testing with nfs using multiple machines pounding the one server. I was just going to run postmark on the 3 clients machines (starting out at the same time). Ultimately I dont give a toss if one is 10% or even 20% better than the other. For that money, a few hundred dollars in RAM and CPU would change that. We are mostly a BSD shop so I dont want to deploy a LINUX box for 25% faster disk I/O. But if the differences are far more acute, I need to perhaps take a bit more notice. > The read tests are less clear. iozone runs its read tests just after > it runs its write tests. so filesystem syncing and write flushing is > going to have a huge effect on the read numbers. I suspect that this > is skewing the results across the spectrum. In particular, I don't > see anywhere near the difference in cache-read performance between > FreeBSD-5 and DragonFly. But I guess I'll have to load up a few test > boxes myself and do my own comparisons to figure out what is going on. > > -Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6.2.1.2.0.20050202170217.02d509e0>