Date: Tue, 25 Jun 1996 10:42:39 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: hua@xenon.chromatic.com (Ernest Hua) Cc: dgy@rtd.com, jsigmon@www.hsc.wvu.edu, hackers@freebsd.org, hua@xenon.chromatic.com Subject: Re: Memory tests ... Message-ID: <199606250112.KAA24941@genesis.atrad.adelaide.edu.au> In-Reply-To: <199606241700.KAA16970@server1.chromatic.com> from "Ernest Hua" at Jun 24, 96 10:00:26 am
next in thread | previous in thread | raw e-mail | index | archive | help
Ernest Hua stands accused of saying: > > > > Are people looking for *exhaustive* tests, "quick and dirty" tests, > > diagnostic tests, or what? There are different solutions for each > > of these. But I think just the "make world" style tests add very little > > value (tho' prehaps, they are probably easiest to invoke...) > > I would prefer a thorough set of tests such as some reasonably optimized > 1's and 0's test. I'm not familiar with algorithms for testing "flaky" > versus "stuck". The problem is that no program can generate sequential accesses _fast_ enough, and has no way of watching the critical timing parameters that will help you decide _how_ marginal a given memory is. For this you need a _real_ memory tester, and because measuring nanosconds accurately is difficult, thee cost _lots_ of money. 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. > Ern -- ]] 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?199606250112.KAA24941>