Subject: Re: some performance diff with getc()/putc() between FreeBSD and NetBSD?
To: NetBSD-current Discussion List <current-users@NetBSD.ORG>
From: Paul Ripke <firstname.lastname@example.org>
Date: 05/07/2003 08:44:12
On Wednesday, May 7, 2003, at 04:54 Australia/Sydney, Greg A. Woods
> [ On Tuesday, May 6, 2003 at 13:09:48 (-0400), I wrote: ]
>> Subject: Re: some performance diff with getc()/putc() between FreeBSD
>> and NetBSD?
>> [ On Tuesday, May 6, 2003 at 22:41:08 (+1000), Paul Ripke wrote: ]
>>> Subject: Re: some performance diff with getc()/putc() between
>>> FreeBSD and NetBSD?
>>> OK, what concerns me is those "random seeks/sec" rates. There's a
>>> difference there, and that could hurt other stats. It shouldn't be
>>> bound (obviously), the only thing that comes to mind is in disk
>>> I/O scheduling - disksort. I wonder what the difference is.
>> Yes, that concerns me a bit too.
>> I'm not sure how to quantify the difference in seeks/sec though.
> I'm not sure if I've discovered something even worse, or just an
> artifact in the way bonnie's measurements work.
> Observe what happens when I more than double the size of the file:
> -------Sequential Output-------- ---Sequential Input--
> -Per Char- --Block--- -Rewrite-- -Per Char- --Block---
> Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU
> /sec %CPU
> NBSD-ATA 3000 41865 34.7 40128 13.2 10464 2.8 40413 34.4 40832 6.0
> 93.9 0.5
> NBSD-ATA 8192 39055 29.5 33559 11.5 9421 2.6 33608 27.7 33738 5.0
> 427.4 0.9
> NBSDRF10 3000 78534 66.6 78926 26.5 13895 5.9 87662 81.2 119517 26.2
> 276.9 2.9
> NBSDRF10 8192 77872 61.2 78070 26.0 13961 6.0 92764 83.9 122623 27.3
> 1014.1 3.0
> Note these measurements are all taken with a block size of 16384 bytes,
> the default for Netbsd pkgsrc/benchmarks/bonnie prior to my patches
> adding a chunk-size command-line option. FreeBSD
> used a default of 8192 bytes. However reducing that size to 8192 on
> NetBSD does not significantly affect the seeks/sec nor the rewrite
> throughput in any way.
> While the rewrite throughput doesn't change, the seeks/sec improves
> considerably..... On first glance this seems very counter-intuitive.
> Normally the bigger the file the closer the seek time approaches the
> actual seek time of the underlying hardware. While that may be exactly
> what's happening here, it's still odd because it's essentially
> here since the smaller the file then the longer the average seek time.
The only other thing that comes to mind is allocation policies and
filesystem layout - allocation groups, maxbpg, etc. A smallish 3 GB file
may be spread thinner over the disk, and disksort can't get much of a
8 GB file is spread a little thicker and disksort can get more benefits.
Or maybe I just need my morning caffeine fix...
101 reasons why you can't find your Sysadmin:
68: It's 9AM. He/She is not working that late.
-- Koos van den Hout