Date: Thu, 17 Feb 2000 12:27:52 -0800 (PST) From: Tom <tom@uniserve.com> To: Brad Knowles <blk@skynet.be> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Initial performance testing w/ postmark & softupdates... Message-ID: <Pine.BSF.4.05.10002171205530.1712-100000@shell.uniserve.ca> In-Reply-To: <v04220823b4d1f68c1f85@[195.238.1.121]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 17 Feb 2000, Brad Knowles wrote: > > I'm not sure how comparing benchmark results from 1998 with current > > hardware is relevant at all. Postmark is performance is influenced more > > by the disk & controller used, rather than the OS. In fact, CPU is not > > much of any issue either. In fact, SMP is probably slowing the results > > down! > > My results clearly show that there is a huge filesystem effect, > and anything that could prevent operations from getting put into the > queue to be flushed to disk would have a similar effect. > OS/filesystem implementation efficiency could not *help* but have a > huge impact on this. Not really. You could just use async updates instead of softupdates. Or an OS that uses async updates. Write caching metadata is always faster than re-ordering it intelligently. ... > I also notice that softupdates on a slow disk beat out > Linux/ext2fs+async on a single CPU system that was otherwise > similarly configured, except for the DPT SmartRAID V controller that > the Linux server had to it's advantage, and the 5-way RAID-5 volume > that it was writing to. Perhaps. Or it was the rather new SmartRAID V driver. Or it was the card (there are many different SmartRAID V) models. Or the array was optimized for sequentional io, instead of random io, not that RAID5 is ever optimal for random io to begin with. > > They came with Wide SCSI disks (not Ultra, not > > Ultra2) for instance. It doesn't mention, but I expect the test was only > > done over 100BaseT. In that case, the 100BaseT network would have been > > the limiting factor. > > Yes, it was 100BaseT, but I don't see anything in any of these > tests that should have come anywhere close to pushing the limits of > 100BaseT for speed -- ~400KBps read and ~600KBps write, with ~170 TPS > shouldn't come anywhere close to network bottlenecks of 12.5MBps > capacity. The rates reported by postmark are aggregates. I've noticed that actually throughput over the tests to vary by a 100% or more during the tests. Besides, latency of 100BaseT is rather poor too. ... > > So please, postmark is a useful tool. See my previous e-mails about > > postmark+softupdates. But comparing results when a two year old document > > is meaningless. Especially with disk/controller performance doubling > > every year or so. > > Their performance may theoretically be doubling every year or so, > but the machine I tested with is not anywhere close to what I would > consider to be a high-end server, and it definitely did not have the > advantage of a vinum nine-way striped filesystem on 10kRPM disks or > anything like that, and yet I still came pretty close to their level > of performance. Not just their (NetApp) performance. Disks and controllers in general are a lot faster than they were two years ago. Please forget all those old results. My point here is not to defend NetApp, but to say that old results are meaningless. Big deal. You managed to exceed some results published over two years ago. I bet my TV can exceed the postmark scores you published today, two years from now. Tom Uniserve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.10002171205530.1712-100000>