🚀 go-pugleaf

>In article <BuzM7w.MAI.2@cs.cmu.edu> ddj+@cs.cmu.edu (Doug DeJulio) writes:
>I just had another idea concerning the relative speeds of 3.0 and 2.1.
>
>One user reported that booting with -nbuf=32 sped up the system
>considerably.
>..
>
>Can a bunch of people with various configurations try out booting with
>the -nbuf=32 switch to see if it's a consistant performance
>improvement?  Can people who upgraded using Upgrade.app and those who
>upgraded using BuildDisk compare notes to see if there's a big
>performance difference?
>
>I would try to take part in this effort, but I haven't got my 3.0
>CD-ROM yet (got the *drive* weeks ago though).

    I upped my buffers to 99 and it resulted in a substantial improvement
    under 3.0

    In terms of the disk latency, here is what my disktest program dumps

    with the standard latency of 4ms nbuf=16 (default)

16 files x 1048576 KB blksize 512 read: 963653 bytes/sec  write: 721290 bytes/sec
16 files x 1048576 KB blksize 1024 read: 1139756 bytes/sec  write: 669214 bytes/sec
16 files x 1048576 KB blksize 4096 read: 1054507 bytes/sec  write: 713620 bytes/sec
16 files x 1048576 KB blksize 8192 read: 1039480 bytes/sec  write: 712105 bytes/sec
16 files x 1048576 KB blksize 32768 read: 981697 bytes/sec  write: 757094 bytes/sec
16 files x 1048576 KB blksize 131072 read: 980550 bytes/sec  write: 646022 bytes/sec
poof!

    with the standard latency of 4ms, non-standard nbuf=99

16 files x 1048576 KB blksize 512 read: 912797 bytes/sec  write: 989222 bytes/sec
16 files x 1048576 KB blksize 1024 read: 921318 bytes/sec  write: 999238 bytes/sec
16 files x 1048576 KB blksize 4096 read: 923855 bytes/sec  write: 1018653 bytes/sec
16 files x 1048576 KB blksize 8192 read: 922331 bytes/sec  write: 1031809 bytes/sec
16 files x 1048576 KB blksize 32768 read: 927943 bytes/sec  write: 1023625 bytes/sec
16 files x 1048576 KB blksize 131072 read: 932585 bytes/sec  write: 942011 bytes/sec
poof!

    with a latency of 2ms, nbuf=99

16 files x 1048576 KB blksize 512 read: 909827 bytes/sec  write: 1041416 bytes/sec
16 files x 1048576 KB blksize 1024 read: 928456 bytes/sec  write: 966429 bytes/sec
16 files x 1048576 KB blksize 4096 read: 941482 bytes/sec  write: 1024250 bytes/sec
16 files x 1048576 KB blksize 8192 read: 969221 bytes/sec  write: 967544 bytes/sec
16 files x 1048576 KB blksize 32768 read: 971465 bytes/sec  write: 1024875 bytes/sec
16 files x 1048576 KB blksize 131072 read: 1014955 bytes/sec  write: 1009459 bytes/sec
poof!

    And with a latency of 0ms (and maxblocks set to 32), nbuf=99

16 files x 1048576 KB blksize 512 read: 1111810 bytes/sec  write: 426792 bytes/sec
16 files x 1048576 KB blksize 1024 read: 1221938 bytes/sec  write: 446202 bytes/sec
16 files x 1048576 KB blksize 4096 read: 1188188 bytes/sec  write: 442904 bytes/sec
16 files x 1048576 KB blksize 8192 read: 1197517 bytes/sec  write: 452459 bytes/sec
16 files x 1048576 KB blksize 32768 read: 1182326 bytes/sec  write: 426901 bytes/sec
16 files x 1048576 KB blksize 131072 read: 1200086 bytes/sec  write: 442553 bytes/sec
poof!

    THESE TESTS WERE DONE ON A BRAND SPANKING NEW NeXTStation Turbo Slab
    Mono (040/33Mhz), YOUR RESULTS WILL BE GUARENTEED TO VARY DEPENDING ON
    YOUR MACHINE AND YOUR HARD DRIVE.

    NOTE!  Changing your disk latency will NOT improve the perceived speed
    of your system for the better simply because it only effects files
    created *after* the change, and also because your swapfile and NeXT
    apps have already been layed out optimally by the disk builder (or so
    people have said).	Changing your disk latency will NOT effect swap
    performance.  (for swap files that grow beyond the base size, it is
    doubtful that performance will increase due to fragmentation, but
    ignoring that, the read performance may increase and write performance
    will decrease.  Note that the majority of swap operations are read
    operations).

    Whether or not this (tunefs) will improve the perceived speed of 3rd
    party apps you install, I simply do not know, but the absolute best it
    will do is improve the initial load speed and perhaps document-load
    speed.  It certainly will NOT improve document save speed.

    NOTE!  Running tunefs on a mounted filesystem does not work because the
    superblock is not stored in the normal buffer cache, and the 'old'
    block will be written out on shutdown/reboot.  It's a bitch to change
    and I've done so half a dozen times only because I am an overly curious
    person. I strongly suggest that you DO NOT screw with tunefs yourself.

    NOTE! TUNEFS ONLY EFFECTS FILES CREATED AFTER TUNEFS WAS SUCCESSFULLY
    RUN.  I STRONGLY SUGGEST YOU DO NOT FOOL AROUND WITH TUNEFS!

    However, I would like to point out the dramatic increase in throughput
    you get for write operations when you change the nbufs value.  This
    will also result in a noticable speed improvement for the system, the
    reason being that *any* file access bumps the access time in the inode
    and writes out the inode.  Since this is a non-critical operation the
    write will be buffered.  The more NBUFS you have, the more files you
    can access simultaniously without forcing inode updates.  Since data
    blocks are also buffered to a degree, the filesystem can write files
    more efficiently as well (though, since the BSD filesystem does not do
    multi-block transfers, the buffering does NOT allow you to set the
    latency field to 0).


				    -Matt

>--
>Doug DeJulio
>ddj+@cmu.edu

--

    Matthew Dillon		dillon@Overload.Berkeley.CA.US
    1005 Apollo Way		uunet.uu.net!overload!dillon
    Incline Village, NV. 89451	ham: KC6LVW (no mail drop)
    USA 			Sandel-Avery Engineering (702)831-8000