🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.next.misc
Article #2456

Re: Ramdisk coming for NeXT

#2456
From: Scott Hess
Date: Mon, 17 Aug 1992 14:24
54 lines
3157 bytes
[Sorry if this article is a repeat - but it never seemed to show
up on our newsfeed, and nobody's replied anyhow.  Perhaps we've
got NNTP problems?  I don't know.]

In article <1992Aug13.151354.11149@Informatik.TU-Muenchen.DE>
	MeyerGru@Informatik.TU-Muenchen.DE (Uwe Meyer-Gruhl) writes:
>Oh. I forgot something. For those of you who _really_ want to
>optimize their access speeds: It is possible to tell MACH how many
>buffers you want at bootstrap time without actually patching /sdmach.
>Just use 'b sd() sdmach nbuf=128' or any number you like instead
>of 128.  Mileages may vary according to individual application
>profiles.

And, in article <1992Aug14.091704.15202@leland.Stanford.EDU>
	marcu@leland.Stanford.EDU (Marc Albert Ullman) writes:
>I had a quick question for you concerning this patch.  I have been
>using a similar modification consisting of only the word at 604776
>and I do see a noticeable difference in performance.  Do have any
>evidence to confirm that it is necessary to NOP out the other
>instructions that you refer to?
<...>
>P.P.S  I have been using 0x40 = 0100 = 64 = 512KB of buffers on a
>       40MB cube.  Did you do any testing with differing values
>       and if so what did you find?  It would be nice if NeXT had
>       some sort of adaptive algorithm based on the amount of total
>       system RAM.

Could anyone elaborate on any and all performance improvements
noted?  My sneaking suspicion is that this is like memory upgrades
from 16M to 32M - 8M to 16M is obvious, but it took me around a
month to really realize that the 32M was quite a bit better than
the 16M.

I've tried upping my buffers.  I've got 32M on a standalone monochrome
system, and it's mainly used for Edit, Stuart, and InterfaceBuilder
(sometimes), so figuring I could afford the memory, I started
testing values and seeing what they did to make/compiles.  There
appears to be an upper limit in that the startup message might
_say_ that it's got 1024 buffers, but it only allocates 3.19M
(408*8192).

In any case, I noted _no_ difference in compilation speed.  The
CPU utilization appeared to be slightly better with more buffers,
but it's not really enough that I'd be confident in recommending
pumping the values up too high.  64 would probably be great, but
higher values didn't seem to help very much at all.  Of course,
this might all be a result of something else entirely - but I'm
tired of rebooting my computer, so we won't find that out from me ...

Later,
--
scott hess <shess@ssesco.com>  <Who achieved programmer nirvana on Aug 11th>
12901 Upton Avenue South, #326  Burnsville, MN 55337 (612) 895-1208 Anytime!
   <Text: One Class to bring them all and in the darkness bind them ...>
Technical Details
Message-ID: <SCOTT.92Aug17092422@nic.gac.edu>
Path: arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!sample.eng.ohio-state.edu!purdue!news.cs.indiana.edu!umn.edu!msus1.msus.edu!gacvx2.gac.edu!gacvax2!scott

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!sample.eng.ohio-state.edu!purdue!news.cs.indiana.edu!umn.edu!msus1.msus.edu!gacvx2.gac.edu!gacvax2!scott
From: scott@nic.gac.edu (Scott Hess)
Newsgroups: comp.sys.next.misc
Subject: Re: Ramdisk coming for NeXT
Message-ID: <SCOTT.92Aug17092422@nic.gac.edu>
Date: 17 Aug 92 14:24:22 GMT
Organization: Gustavus Adolphus College
Lines: 54