Re: Computer Flake Outs (was: Re: On Overclocking - READ THIS!)

Dave Ahn (
Wed, 7 May 1997 02:34:19 -0400 (EDT)

[Re: potential faulty results from overclocked CPU's]

The problem doesn't lie only with overclocked CPU's. There are many PC's
out there running DOS/Linux/whatever that have borderline or misconfigured
hardware. Those of you familiar with the "gcc: internal compiler error 11"
know what I'm talking about. In particular, motherboards and SIMMs (as
well as other hardware not relevant to deschall, like disk controllers, etc)
can simply fail when used at a level very close to their maximum performance.

Just as an example, I will cite an experiment I performed last year on a
group of a total of 20 486's and Pentium PC's, nearly all of different
configuration, quality, and manufacturer. Some of these PC's had overclocked
CPU's. I did 3 tests to determine whether each machine would be "stable"
under heavy CPU load. The tests were nowhere near perfect, but they gave
an indication, if they failed.

1. Ran Norton Utilities' extended system diagnostics (including memory tests)
2. Ran Doom2 in replay mode for a period of 12 hours
3. Ran a script to repeatedly compile a linux kernel for 12 hours.

All of them, with the exception of one of the Pentiums, passed the first
two tests. 5 of them, excluding the Pentium that failed test #2, failed
test #3, generating compiler error 11 or locking up the system. Of
the 5, 2 were 486's and 3 were Pentiums, and 1 of the Pentiums was
overclocked from 90->100.

To make the long story short, 2 machines, both Pentiums, could not
be reconfigured (running the CPUs at their rated speed) to pass all three
tests. Others were correctable problems stemming from bad BIOS configs.
It should be noted that none of these PC's exhibited any signs of
problems under "normal" use in DOS/Windows/Linux.

There are a lot of PC's out there running deschall. Some of them are
bound to have borderline or poorly configured hardware that may fail
under heavy load. Since deschall is a small client that is CPU and
memory (fetch) intensive, I would recommend that PC users should at
the least double check their BIOS settings for memory wait states
and make sure that their SIMMs and SRAM chips (cache) meet the minimum
ratings required by the memory bus speed (of the motherboard and CPU).

It may be a good idea to implement some kind of double-checking mechanism
on the deschall client side, that either the client itself self-triggers
at a consecutively increasing interval, or that can be triggered by a
'SELFTEST' packet sent by the server. For example, the test cases
might be:
startup: 30 second test of encrypting and rechecking the encryption.
after processing 1 peaked keyspace: 2 minute self test.
after processing 5 peaked keyspaces: 2 minute self test.
each 20 keyspaces thereafter: 2 minute self test.

The overhead is miniscule and worthwhile.


Dave Ahn,             "When you were born you cried, and the
       world rejoiced.  Try to live your life
Virtual Endoscopy Center                 so that when you die you will rejoice,
Bowman Gray School of Medicine           and the world will cry."  -1/2 jj^2