Messages in this thread |  | | From | Systemkennung Linux <> | Subject | Re: Linux & ECC memory | Date | Wed, 20 Nov 1996 20:46:01 +0100 (MET) |
| |
> This is an interesting conversation... > > In the early 80s, ECC memory was important to computer systems. > > Now, personal computers have enormous arrays with non-parity memory.
Because RAM is a scarce resource such that even the parity bits account for a substancial part of the price of a memory module. Read: Joe Cloner can build a system cheaper and increase his gain by that.
> Is this information written down anyplace? > 1) is there much to be gained by having parity memory (many systems > do not).
Definately yes. Not for Joe-My-Game-Has-Crashed-So-Just-Reboot but if it's mission critical or just protect your valuable data then parity/ECC is usefull. For _big_ systems ECC is very valuable because it's the only thing that helps you to verify the correct function of a system or even keeps a failing system alive when RAM is defective. (I've got an old numbercruncher at home which is useable though one of the SIP modules is missing ...)
> 2) Are there ways to programmatically to turn the cache off (is L1 > always on?)
Those systems that I known the system interface of cloer usually control the cachability of a extern memory reference by some CPU generated cache disable signal.
CPUs that don't have cache support in the CPU completly rely on the help of a chipset for that purpose. Among those CPUs are the i386 (?), Motorola 68k series before the 68020.
> Any performance number with/without cache?
With current computer systems the performance increase by caching is often 30 and more. Just because I have those numbers in my mind - R4400/133MHz with caching enabled makes ~67.11 BogoMIPS, with caching disabled 2.35 BogoMIPS.
When comparing these number you should consider that there are systems that
- are clocked much faster and therefore have a bigger difference in performance between memory and primary cache bandwidth. - the BogoMIPS loop is very small. This allows a memory controller to make best possible use of available fast memory access modes like page mode etc.
So for "real" apps the performance numbers should look even bit worse.
Ralf
|  |