Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 25 Jun 1996 19:15:51 +0930 (CST)
From:      Michael Smith <msmith@atrad.adelaide.edu.au>
To:        dgy@rtd.com (Don Yuniskis)
Cc:        msmith@atrad.adelaide.edu.au, hua@xenon.chromatic.com, dgy@rtd.com, jsigmon@www.hsc.wvu.edu, hackers@freebsd.org
Subject:   Re: Memory tests ...
Message-ID:  <199606250945.TAA29306@genesis.atrad.adelaide.edu.au>
In-Reply-To: <199606250900.CAA01330@seagull.rtd.com> from "Don Yuniskis" at Jun 25, 96 02:00:04 am

next in thread | previous in thread | raw e-mail | index | archive | help
Don Yuniskis stands accused of saying:
> > 
> > So if you just want a 'does it work, yes/no' answer, put the memory into
> > your favorite high-performance OS (I prefer FreeBSD, OS/2 and Novell are 
> > also popular), and thrash it mercilessly for a few days.
> 
> I don't see the value of this -- except for the fact that it's "easy"
> to invoke from a shell  :>   If the system seizes up, it just tells
> you something died (most probably memory).  You are counting on the
> failure to happen in such a way as to corrupt the state of the
> processor irrevocably.

Yup, and giving the system a hard workout leads to lots of page reusage and
a fairly good chance of having most pages in the system exercised with code
or critical data.

> I find use of a LFSR with a long, "relatively prime" period to 
> alternately fill and check memory contents is great as a quick
> POST-style check.  It can also be used for more thorough testing
> (i.e. to catch thermal problems) if set in an endless loop.  And,
> unlike just running a system hard for a while, it (usually)
> survives a memory failure and can report on the failure.
> 
> Of course, this *doesn't* test other hardware that may be marginal,
> etc. (i.e. DMAC's).

... nor does it consider crosstalk, or parts with marginal timing 
characteristics that take a little too long to deliver the data if the
rail sags or spikes at the wrong time, or...

Yes, the 'thrash' test is primitive, but it's highly statistical by 
nature, and at the end of the day, the results are generally pretty
good.

> --don

Rant rant rant 8)

-- 
]] Mike Smith, Software Engineer        msmith@atrad.adelaide.edu.au    [[
]] Genesis Software                     genesis@atrad.adelaide.edu.au   [[
]] High-speed data acquisition and      (GSM mobile) 0411-222-496       [[
]] realtime instrument control          (ph/fax)  +61-8-267-3039        [[
]] Collector of old Unix hardware.      "Where are your PEZ?" The Tick  [[



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606250945.TAA29306>