[ On Tue, April  9, 1996 at 17:51:34 (-0700), Curt Sampson wrote: ]
> Subject: Re: seemingly dismal performance of NetBSD-1.1A/sun3 file I/O....
>
> This is just a thought, but has there been any attempt to analyse
> the CPU usage of filesystem operations and perhaps optimise them?

Having had lots of experience with kernel profiling in SysVr3.2, I sure
wish it or something similar was available for NetBSD.

I've been too busy lately to get bonnie and lmbench run in the proper
environments on these machines, but hopefully in the next week....

I suppose I should try compiling lmbench with the same compiler in both
environments too (and also run the SunOS binary under NetBSD), but
that'll delay me somewhat further as I don't have a GCC on this SunOS.

> I've got a 486/100 with an NCR controller and a P90 with a Buslogic
> controller, both with an HP Surestore 5400 RPM disk drive (among
> others). Using iozone, the P90 gets about 4MB/sec on the HP drive,
> the 486/100 gets about 1.5 MB/sec. The results on the 486/100 vary
> depending on whether the filesystem is small or large, and how full
> it is. The P90 doesn't. This leads me to suspect that something in
> the CPU may be a limiting factor here.

Interesting indeed.  I have these numbers from a 32 MB P133 with a PCI
NCR 53c810 SCSI controller on a QUANTUM XP34301 drive with about a 1GB
filesystem that has been heavily used:

        IOZONE: Performance Test of Sequential File I/O  --  V2.01 (10/21/94)
                By Bill Norcott

        Operating System: POSIX 1003.1-1990 -- using fsync()

IOZONE: auto-test mode 

        MB      reclen  bytes/sec written   bytes/sec read      
        1       512     3177503             1565038             
        1       1024    2688656             1542023             
        1       2048    3177503             17476266            
        1       4096    3084047             20971520            
        1       8192    3084047             20971519            
        2       512     3437954             1625699             
        2       1024    3130077             1823610             
        2       2048    3679214             2076388             
        2       4096    3437954             1997287             
        2       8192    3437954             1997287             
        4       512     3956890             2589076             
        4       1024    3679214             2242943             
        4       2048    3994575             2796202             
        4       4096    3883614             2759410             
        4       8192    3744914             2741375             
        8       512     3778652             3095427             
        8       1024    3830414             3368918             
        8       2048    3901678             3539497             
        8       4096    3975643             3539497             
        8       8192    3663147             3466366             
        16      512     3839179             3348745             
        16      1024    3901678             3389336             
        16      2048    3874645             3532045             
        16      4096    3919910             3883614             
        16      8192    3865717             3938313             
Completed series of tests

I think the near steady increase in read rates after the drop at 2MB is
very weird too.

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>