[ On Fri, July 31, 1998 at 10:16:13 (+0200), Peter Koch wrote: ]
> Subject: Re: emacs-18.59
>
> >Having more than 16MB or RAM definitely helps things out though,
> >esp. under NetBSD (as opposed to SunOS).
>=20
> Don=B4t talk nonsense!
> SunOS makes GREAT use of every Meg!

But that's exactly what I mean!  ;-)

> IMHO, a 3/260 can really make use of 64MB and a 3/470
> can really make use of 128MB.

My 3/260 was amazingly fast with 128MB (as opposed to 48MB, which is
what it had earlier -- two 16MB's and two 8MB's).  It hardly ever paged=

at all, and of course with SunOS it had much much better buffer cache
performance than NetBSD gets.

Once I've settled into my new house, and the weather's cooled down
again, I'll try firing up the 3/280 again and running NetBSD on it.

> NetBSD without UVM does not make ANY use of more memory
> as long as the current configuration does not need to
> page, which is undoubtly true for ALMOST everyone of
> us, who still runs a Sun3.

If you're not paging in the first place I'm not sure how UVM will even
make any difference (slightly fast process startup times, and of course=

a true vfork() may help).

> With UVM, things start to change, but i BET, SunOS is
> still much faster in most things. And makes better use
> of the resources, especially main memory.

Absolutely, esp. for any jobs that frequently access some of the same
files, such as big compiles.  NetBSD needs much better disk buffer cach=
e
management algorithms (ala FreeBSD's, for example!  ;-)

> There is a known effect called PMAP-thrashing, which
> starts to occur at 64MB on SunOS 4.1.1, but can be
> patched with "adb". I don=B4t know, if the sun3x
> architecture does have this effect too, because it
> uses another type of MMU.

I don't think I ever saw anything like that on the 3/280.

> I have one 32MB board, which works in my 3/470. The
> machine crashes every week with a memory fault.

OK, well that probably rules out the problem being only in the 3200
series CPU, since that's almost exactly the same behaviour I got with
any combination of 32MB boards and their half-populated 16MB cousins.

I've got at least one spare 32MB board in good working order and severa=
l
16MB ones.  I've also tried almost every variant of the 3200 CPU board =
I
can get my hands on (a total of about four or six revisions).

> I=B4d say, the memory boards have become old and flaky.

I doubt it.  At first I thought it might be a software problem (I can
only re-start my boards after a failure by either power cycling or by
going into the PROM diagnostics (x), quiting back to the PROM command
prompt (q), and then doing a system reset (k2).  A plain (k2) will fail=

to re-initialize the memory, then the PROM will get lost too and a powe=
r
cycle is the only way out.

I've only ever had very very rare ECC errors recorded.  None of my 8MB
boards have ever been flakey at all -- I've another 3/260 currently
running something like NetBSD 1.1, and other than the very odd ECC erro=
r
(once a month or less), it works fine too.  Unfortunately NetBSD/sun3
doesn't support ECC fully and the only hack I tried on it ended up
putting the machine into a loop spewing debug messages.

My suspicion is that the 32MB/16MB boards have either a design flaw wit=
h
their DRAM refresh logic, or an interface problem (timing?) with the bu=
s.
I've also tried several different backplanes in 3/260's, and the 3/280
with the newest looking backplane did run slightly better, at least tha=
t
was my objective perception.  That may have been just due to better
cooling in the 3/280 -- I had no fan tray for it so I installed an extr=
a
rack cabinet fan and installed baffles so no air could flow around or
behind the 280 chassis for a total of about 500CFM air flow.

> One hint: Search for the bus terminators! These are

I've built too many VME Sun3's to make that mistake, though I did try
several different packs and checked them all with an ohmmeter too.  ;-)=


--=20
=09=09=09=09=09=09=09Greg A. Woods

+1 416 443-1734      VE3TCP      <gwoods@acm.org>      <robohack!woods>=

Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>=