[lkml]   [1996]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Linux & ECC memory

    > 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

    - 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.


     \ /
      Last update: 2005-03-22 13:38    [W:0.018 / U:0.480 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site