Hello KerSamson

Reference: KerSamson [Jun 13, 2011 9:19:09 AM] post

Greetings.

For my ASUS M4A88T-M LE motherboard, I had BIOS_v0306 which is posted on the ASUS website as having a date of publication (or availability) of -- 2011.03.18. There is a newer version, BIOS_v0307, which I have seen just now (2011.07.05Tu.0915.UTC), with a posted date of publication (or availability) of -- 2011.06.21. Where BIOS_v0306 is dubbed at the said website as "Improve system stability", the newer BIOS_v0307 is dubbed as "Improve Memory compatibility".

I'll first download the BIOS_v0307 and next install it, and from there I'll try out some CMD2 WUs and take the setup for a spin. I'll post the results.

Thanks for the tip.

Good day
;

So, I did flush the old BIOS_v0306, and next installed the latestVersion, BIOS_v0307. I then downloaded some CMD2 WUs, and then started crunching them CMD2 WUs. As before, I'm doing exclusiveProject per machine; in this case, an all-CMD2 crunching in a 6-core machine. (I figured that exclusiveCrunching would sit well with DCF calculations)

Some validation results are now in (asOf_2011.07.07Th.1545):
a] pendingValidation (WingWU=inProgress): 17
b] valid (WingWU=valid): 6
c] inconclusive: 1 (1stWingWU=inconclusive; 2ndWingWU=inProgress)

The above data shows only 1-inconclusive out of 7-evaluated so that the worstCase failRate at the moment should not be greater than 1/7 or about 14.28%. Acceptable? Not bad, I'd say, although I still don't want inconclusives for any of my crunched WUs.

Now, of the six(6) valid CMD2 WUs, the wingWU almost always gets a higher points regardless of whether the wingWU took shorter or longer timeToComplete than my WU. Also, my WU almost always overclaims (up to 2.6x) relative to the wingWU. All these things shake out (in the over-all) so that my WU ends up almost always getting the short end of the quorum. Is it just the luck of the draw? WCG, please look into this.

David_L6:Good advise. One thing I have learned is that the CMD2_v6.40 WUs that I'm getting for my AMD-Ubuntu machine does not seem to do as well on overclock compared to how HFCC_v6.40, HCC_v6.40 or C4CW_v6.40 did. It is BOINC that first exhibits weirdness (flickering fonts, lines, GUI elements) before the CMD2 WU does (CMD2 progressPercentage swinging wildly, for example, from 10% to 180% every second). By the time I detect the BOINC weird display, the damage may have already been done: the inProgress CMD2 WU may have been already doomed to fail the coming validation as first an inconclusive WU and then the fatal INVALID at the end of the WCG validation. My Intel-Vista machine seems better at handling overclocked situations if the fewer CMD2 faults on that machine is any indication.


knreed:Beats me as well; too high an overclock is looking to be the culprit. In any case, how feasible is the idea of inserting a routine that stops all calculations if a NaN (for any reason, not just from tooHighOverclock) is encountered?


robertmiles: Hmm... I do get the weird BOINC display almost as a alarm that a CMD2 WU is about to fail (if not in fact already failed), but the CMD2 calculations seem to continue instead of exiting. An NaN escapeHatch routine would have come handy and provided a means for an automatic and elegant program exit?
;

You'd not be alone looking for an escape hatch from the Nanny state....