Would it be possible for you to give us a little insight how invalid claims are being determined?
We are running a lot of PCs that are faster than the average, so that might be an issue for the algorithm.

Human eyes have considerable trouble seeing the thing that is causing the invalid status. It's spotted by the validator software at WCG. If you could compare your invalid results with the 3 that were declared valid you would see your results do not match the other 3. The valid results all match each other so yours is considered to have errors and is declared invalid.



It depends what you mean by "good" and "accepted".

When WCG "accepts" our results that simply means our end did not detect any crunch errors. Unfortunately, our end cannot detect all errors. So when WCG "accepts" a result, the result is considered to be "good" to the extent that it might prove to be error free when compared with 2 other results. If it does match 2 others then and only then does it receive valid status.



Putting them on another project that uses a 3 quorum like WCG will likely just get you more invalid results. On the other hand, it depends how closely they compare the 3 results. Some projects do a bitwise compare while others do a less stringent compare.

As Didactylos said, run the diagnostics and see what comes up. It could be any one of a number of things and it may take a lot of work to find the problem. The problem is not discernible from error reports because your results are not showing errors. Yet we know there are errors because they do not match 3 other results. It could even be something as tricky as an intermittent fault in a NIC or cable which introduces an error into the result when it uploads to WCG..

On the present generation there is to my knowledge no special CPU registry recognition, which the future BOiNC has. Since it is important that all calculations in a quorum are performed in an identical way and absent the extra feature recognition, it cannot be risked to use SSE2 on one in the quorum and not having SSE2 on another machine in the quorum with a distribution going like one to P3, second to P4 and third to C2D.

Rom Walton wrote an article about the blessing/curse of this: Part 1 & 2

http://www.romwnet.org/dasblogce/PermaLink,gu...2d-ba21-5bb6b310b295.aspx
http://www.romwnet.org/dasblogce/PermaLink,gu...55-824d-057757002768.aspx

Here a quote of a post in June of Lawrencehardin:

The BOiNC development is going towards making quorums to go e.g. all to C2D. I don't know, but the logic and management at the server level will be a whole lot more complicated as it already needs to manage different sets for different OSses like Windows, Linux, Mac.... hence the occasional message like "No work available for your platform"

Hi XS_Fr3ak

There is another "issue" not covered in the known problems above and that is generally speaking, machines with slow processors and/or low ram will claim much higher than fast machines. The slow machines always take longer to complete than their benchmark would indicate.

Observation, lately, indicates machines of similar processor speed have been placed into the same quorum in an effort to reduce outlier invalids. That's what seems to have happened with my slow machines at any rate.

In this example the second machine clearly couldn't produce the points claimed in the time taken to complete:

faah0988_ d143n715_ x1AJX_ 00 Valid 11/25/2006 05:42:05 11/26/2006 18:26:43 12.67 88 / 80
faah0988_ d143n715_ x1AJX_ 00 Invalid 11/25/2006 05:40:58 11/25/2006 14:10:28 5.88 175 / 40
faah0988_ d143n715_ x1AJX_ 00 Valid 11/25/2006 05:31:44 11/25/2006 17:04:05 8.11 71 / 80

In this example the points claimed vary considerably, but the high claiming machine is only claiming 5PPH while the low claiming machine is nearly 16PPH. All were credited OK:

faah0993_ d153n268_ x1AJX_ 00 Valid 11/27/2006 11:17:02 11/27/2006 22:09:43 4.73 75 / 91
faah0993_ d153n268_ x1AJX_ 00 Valid 11/27/2006 11:13:17 11/29/2006 04:44:54 20.16 105 / 91
faah0993_ d153n268_ x1AJX_ 00 Valid 11/27/2006 11:02:39 11/29/2006 01:48:20 19.15 93 / 91

I have even observed machines claiming quorum average points but completing the work much faster than the others being treated as outliers, when in a quorum of slow machines. I haven't seen this happen for more than a week so it may have been changed.

Your over clocked Sempron, theoretically should be low scoring in this case unless it is starved for ram. The other factor, as mentioned earlier is HDC, where if you pause the work and then restart the accumulated points remain and the HDC WU will often start from zero, causing a wildly inflated claim.

If you could supply more information on the type of work, your usage pattern(more than one project?), ram etc,. the answers may be more evident.

Cheers. ozylynx

Hi Sek.

I am aware that my post was somewhat off topic. It was given in reply to some of the questions asked by XS_Fr3ak, in an attempt to clear that away from the discussion, and get back to the topic. i.e. show examples where the points system is working under even extreme situations. I believe that XS_Fr3ak's problems are likely hardware based.

Cheers. ozylynx