A significant fraction (I estimate at least one-half) of the results that have been processed by the KWSN_2.4V_***_MB.exe client and that I am returning to S@H are not validating. The S@H server decides "No consensus" and sends out another WU for someone else to process. In the vast majority of cases, the third WU does produce a consensus, and the WU is retired, but it can take a week or more. About one WU per week is declared invalid.
I return about 110-150 WUs per day, so this is a lot of extra work for the server and society. S@H and society are not helped in terms of energy consumption and global warming if use of the optimized clients causes one-third extra work. Does anyone know why the WUs processed with the optimized clients are not validating initially?
Could the cause be that the optimization effort started with the 5.15 client rather than with the 5.28 cliient?
I predict that S@H is going to forbid use of the optimized clients if they continue to engender extra work and much larger WU database table sizes.
That would be a terrible waste of resources. Could someone please look into this problem?
Ahhh thanks for the extra detail. So my guess is that the higher efficiency of the optimised apps is pushing the OC's/Temps just a little harder than the stock/beta apps. If you stress test with Prime95, for say 24 hours, I suspect that similar stability issues may show [indicating a borderline OC]. If so, then simply backing off a little on the OC may improve matters. Alternatively, If the machine(s) pass(es) the Prime95 'torture test' but still generates the borderline results, maybe the rare compatibility issues and/or settings need to be looked at. [Note: I'm not an OC'ing type guy, There are some very experienced in that willing to help/answer questions over in the number crunching forum at seti@home message boards]Jason
I ran the S@H Beta project on (1/2 stock and 1/2 optimized apps) without problems.