On Wednesday, May 7, 2003, at 04:54 Australia/Sydney, Greg A. Woods 
wrote:

> [ 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 
>>> huge
>>> difference there, and that could hurt other stats. It shouldn't be 
>>> CPU
>>> 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-- 
> --Random--
>               -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- 
> --Seeks---
> 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 
> ports/benchmarks/bonnie
> 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 
> very
> 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 
> backwards
> 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 
win,
8 GB file is spread a little thicker and disksort can get more benefits.
Or maybe I just need my morning caffeine fix...

Cheers,
--
Paul Ripke
Unix/OpenVMS/TSM/DBA
101 reasons why you can't find your Sysadmin:
68: It's 9AM. He/She is not working that late.
-- Koos van den Hout