[comp.sys.next] 120 ns memory

Gerben.Wierda@samba.acs.unc.edu (Gerben Wierda) (03/26/91)

PLEASE REPLY TO:	gerben@rug.nl

I have read a posting on 120ns memory. How do I recognize this? (I have
a cube from april 1989 and I am going to upgrade).

Thanks in advance,

Gerben

--
=============================================================================
	Extended Bulletin Board Service, Research & Development
Office of Information Technology, University of North Carolina at Chapel Hill
	      internet: bbs.acs.unc.edu or 128.109.157.30

eboltz@jhunix.HCF.JHU.EDU (Eric Scott Boltz) (03/26/91)

In article <3103@beguine.UUCP>, Gerben.Wierda@samba.acs.unc.edu (Gerben Wierda) writes:
> PLEASE REPLY TO:	gerben@rug.nl
> 
> I have read a posting on 120ns memory. How do I recognize this? (I have
> a cube from april 1989 and I am going to upgrade).


I bought one of the B-Land cubes. We're talking OLD. Serial # is around
1108 or so. Anyway, I got my 040 and swapped the Simms (8, old 1MB,120ns 
and 4, new, 4MB 80ns) and I've had no problems.

I THINK that the speed rating of the chip is only representative of what
its 'batch' was tested for. There are no real differences in the actual
fabrication process. I had 120ns chips in a MacIIci which wants 80ns for
over a year with no problems.


Basically, if it works then I'd use it.

Eric S. Boltz
The Johns Hopkins University
Dept. of Materials Science and Engineering

madler@nntp-server.caltech.edu (Mark Adler) (03/29/91)

Eric S. Boltz's experience leads him to feel:

>> I had 120ns chips in a MacIIci which wants 80ns for
>> over a year with no problems.
>> 
>> Basically, if it works then I'd use it.

Ah, but how do you know it works?  Flaky memory doesn't always cause
crashes.  If you have parity, then I'd say you have some confidence
that it does, but without parity, you might always wonder about the
results of your calculations ...

I would not be able to recommend to anyone that they use slower
memory than the manufacturer suggests.  Whether it "works" or not.

Mark Adler
madler@pooh.caltech.edu

bennett@mp.cs.niu.edu (Scott Bennett) (03/29/91)

In article <1991Mar28.173631.18960@nntp-server.caltech.edu> madler@nntp-server.caltech.edu (Mark Adler) writes:
>
>Eric S. Boltz's experience leads him to feel:
>
>>> I had 120ns chips in a MacIIci which wants 80ns for
>>> over a year with no problems.
>>> 
>>> Basically, if it works then I'd use it.
>
>Ah, but how do you know it works?  Flaky memory doesn't always cause
>crashes.  If you have parity, then I'd say you have some confidence
>that it does, but without parity, you might always wonder about the
>results of your calculations ...

     Very true.  However, it pays to keep in mind that both the old
NeXTs and the new NeXTs run at 25MHz.  That means that the slowest
memory that could be used (ignoring caching and interleaving) would
have to be 40ns memory, not 80ns or 100ns, *unless* the manufacturer
has designed the rest of the bus hardware to introduce wait states
to give the chips a chance to recover and be ready for the next access.
Indeed this is exactly what all workstation and PC manufacturers do.
Nobody is populating workstations or pee cees with chips that are
that fast (read:  expensive:-).
     The number of times that a wait state is actually needed, though,
is where the manufacturer can make improvements.  If banks of memory
are interleaved, then much of the time no wait state need be introduced
because a lot of memory accesses are done sequentially.  In other words,
successive accesses go to different (alternating or multiply interleaved)
banks, giving each bank time to recuperate before it gets hit again.
Another trick is to use a high-speed cache (usually SRAMs), which can
often reduce the number of actual accesses to main memory chips by
as much as 80%-90%, again *usually* giving the chips plenty of time
to recover.  Combining the caching and interleaving techniques, and
the fact that running processors often do *not* access memory on every
clock cycle *anyway* because that's not what the programs are doing,
result in very few wait states ever being necessary.
>
>I would not be able to recommend to anyone that they use slower
>memory than the manufacturer suggests.  Whether it "works" or not.

     Right.  You might get away with it or you might not.  You may
also not be able to tell whether you are or not.  And you may also
be getting away with it at the moment by dumb luck, but five minutes
from now you might not get a wait state when your slow chips need
it because the bus manufacturer was expecting chips not to need it
under those circumstances.
>
>Mark Adler
>madler@pooh.caltech.edu


                                  Scott Bennett, Comm. ASMELG, CFIAG
                                  Systems Programming
                                  Northern Illinois University
                                  DeKalb, Illinois 60115
**********************************************************************
* Internet:       bennett@cs.niu.edu                                 *
* BITNET:         A01SJB1@NIU                                        *
*--------------------------------------------------------------------*
*  "Well, I don't know, but I've been told, in the heat of the sun   *
*   a man died of cold..."  Oakland, 19 Feb. 1991, first time since  *
*  25 Sept. 1970!!!  Yippee!!!!  Wondering what's NeXT... :-)        *
**********************************************************************