CPU frequency-related S5R2 errors

One of my hosts errored three of its first four S5R2 results in the first two hours of running S5R2. I speculated that the problem might be speed, and have, I think, got very strong corroboration in the last two days.

SUMMARY

host 882945
is a Conroe E6600 on a Gigabyte 965P-DS3 motherboard, presently overclocked to 3.006 GHz under Windows XP SP2. I've used voltage as the exploratory variable:

While 1.31875 was enough to run S5RI, it gave infrequent SETI errors, which only vanished on raising three increments, to 1.34375. S5R2, however, gives errors in less than an hour until the voltage is raised three more increments, to 1.3625.

DETAILS

all for 3.006 GHz

1.31875 ran Einstein S5RI for two full days--no problem
1.325 S5RI OK, one SETI error after 12 hours S5R2 error after 6 minutes
1.33125 SETI error after 16 hours S5R2 error after 12 minutes
1.3375 not tried on SETI S5R2 error after 7 minutes
1.34375 SETI good for days at least S5R2 error after 22 minutes
1.35 S5R2 error after 26 minutes
1.35625 S5R2 error after 11 minutes
1.36250 no S5R2 errors yet (7 hours, two results completed, one credited)

1.375 ran S5R2 without error for two days--seven results complete, several credited

CONCLUSIONS

For my specific system, there are infrequent events both in running SETI (I use the KWSN C2D code) and Einstein S5R2 which require substantially higher CPU speed than does merely booting Windows, running Einstein S5RI, or routine use of browsers, virus checkers, etc. on the system). The speed requirement in running S5R2 is higher than for SETI.

Unless my specific sample of the Conroe CPU has a unique sub-critical fault, it seems likely that other Conroe's of the same stepping which have been deliberately overclocked just close to the point of working on S5RI or SETI will fairly frequently generate speed-related compute errors on S5R2. This can be fixed by backing off on frequency, raising voltage, or both.

I have no basis for guessing what fraction of the S5R2 flood of compute errors fit this syndrome--but I suspect that overclocking is fairly common, and especially so on those posting here.

I think any design has the same risk--if the application is substantially different there is no reason to expect its limiting speed on a particular part to be the same as the previous application. Only testing can tell.

SUGGESTION

If you own a host which behaved well on S5RI, but is generating repeated compute errors on S5R2, try backing off appreciably on frequency, or raising voltage, and report your experience here.

I emphasize the word "appreciably". On my particular system, the S5R2 error behavior was substantially unchanged over a span of six increments of CPU voltage. That is a huge change--when observing Windows boot behavior and other basic measures it would make a night and day difference. If a big shift fixes your problem, you can inch back in to find the edge, but if a small shift makes no difference, nothing is learned.