🚀 go-pugleaf

In article <1992Nov8.130418.19237@wam.umd.edu> gaia@wam.umd.edu (L.  
Anathea Brooks) writes:
> 
> I've changed my boot params using nbuf=128 or rather 
> nbu=128 because of 12 character limit.
> 
> Now, I know this will speed up long compilations, perhaps
> various sorts of number crunching. BUT is there any advantage 
> or speed gain in workaday world? I notice none, and wonder if 
> the memory used by the buffer might be better used as just 
> plain old memory. 

Are you running 3.0?  If so, you should see a noticeable speed  
improvement, particularly when scrolling text windows (such as in Edit)

Also, are you sure that you typed it in correctly.  If so, the first  
messages in a verbose boot should confirm the number of buffers in use.   
The only indication that you get of an incorrect parmeter is that the  
number of buffers reported is 16.

Paul
-- 
Paul Lynch
P & L Systems                   (NeXTmail) paul@seer.demon.co.uk
Tel: (0494)671501                      paull@cix.compulink.co.uk
Fax: (0494)680228                       76711.451@compuserve.com

>>>>> "L." == L. Anathea Brooks <gaia@wam.umd.edu> writes:

    L.> I've changed my boot params using nbuf=128 or rather nbu=128
    L.> because of 12 character limit.

    L.> Now, I know this will speed up long compilations, perhaps
    L.> various sorts of number crunching. BUT is there any advantage
    L.> or speed gain in workaday world? I notice none, and wonder if
    L.> the memory used by the buffer might be better used as just
    L.> plain old memory.

    L.> I ask because I keep hearing people exclaim: "Change buffer
    L.> size in boot params! You'll be amazed!" I'm not. BTW I have
    L.> (only) 16 megs of memory in this NS Turbo.

    L.> This has been discussed but only as per instructions to change
    L.> parameters, not vis a vis advantages/disadvantages.

The .nib file containing nearly all user-interface-objects changed
from beeing a file (2.x) to directory (3.x). While this decision has
some advantages, this has some drawbacks when used with a small block
buffer cache.

Under 2.x the .nib-file gets mapped into the virtual memory when
opened and stays there. This took a single directory scan and a single
open/close pair.

Nowaday the .nib-"file" is a directory. Therefore one scan, open/close
and read is required for each member of the .nib. Unfortunately there
are a lot more files than one knows...

And this is the point, where the increased block-buffer cache speeds
the system. Directory information can be kept (only ?) in the buffer
cache. Because of the frequent open/close operations, even from within
the kernel's namei algorithm, that otherwise would take their way to
the disk, the system acts faster.

But you're right. There are a lot more better ways to use the main
memory... But until we get realy fast disk subsystems we must pay
memory for speed.

	- ralf
--
Ralf E.Stranzenbach  -   (NeXT)-Mail: ralf@reswi.en.open.de
                                Fido: Ralf_Stranzenbach 2:245/5800.12
                       (Voice)-Phone: +49 2302 / 68403
--
Nullum est magnum ingenium sine mixtura dementioe.

If nothing else, do this on any machine that is both an nfs server and  
has a tape drive.

I was getting spurious SCSI buss device resets about every 2-4 hours of  
tape operation.  This was with three different Exabyte drives and 1 HP  
DAT drive on two different Nexts.  Problem went away with a larger nbuf  
number.

I've not a clue why I had these errors and no one else did. No one at  
exabyte or at Next was of help, although the fellow that wrote the SCSI  
driver went to great lengths to try to assist.