🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.next.software
Article #946

Re: nbuf=64/128 theory

#946
From: Ralf E. Stranzenbach
Date: Sun, 08 Nov 1992 23:17
48 lines
2595 bytes
>>>>> "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.
Technical Details
Message-ID: <RALF.92Nov9001749@jodokus.en.open.de>
Path: arc1-ca.pugleaf.net!sparky!uunet!mcsun!Germany.EU.net!horga!reswi!reswi!ralf
References: <1992Nov8.130418.19237@wam.umd.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!mcsun!Germany.EU.net!horga!reswi!reswi!ralf
From: ralf@reswi.en.open.de (Ralf E. Stranzenbach)
Newsgroups: comp.sys.next.software
Subject: Re: nbuf=64/128 theory
Date: 8 Nov 1992 23:17:49 GMT
Organization: News Server fuer en.open.de
Lines: 48
Message-ID: <RALF.92Nov9001749@jodokus.en.open.de>
References: <1992Nov8.130418.19237@wam.umd.edu>
NNTP-Posting-Host: localhost.en.open.de
In-reply-to: gaia@wam.umd.edu's message of Sun, 8 Nov 1992 13:04:18 GMT