With reference to Workunit 90777892:

Three results were apparently received from HD5xxx class ATI boards: one from a 32-bit platform running stock version 0.23, one from a 64-bit platform also running version 0.23, and one from an anonymous 64-bit platform running version 0.20. I would have thought the two 0.23 versions would form a quorum but they apparently did not. The first version 0.23 result (mine) was rejected while the second 0.23 and the 0.20 result were accepted.

Any idea why this would be?

Hi,
i checked my results right now. Since i run the stock app (0.23), only very few results were not validated (~ 2% or so), this seems to be acceptable in a phase, where big problem need to be solved. It looks like things are stabilizing now. Rejection-rate before 0.23 was over 30%.

Alexander

With reference to Workunit 90777892:

Three results were apparently received from HD5xxx class ATI boards: one from a 32-bit platform running stock version 0.23, one from a 64-bit platform also running version 0.23, and one from an anonymous 64-bit platform running version 0.20. I would have thought the two 0.23 versions would form a quorum but they apparently did not. The first version 0.23 result (mine) was rejected while the second 0.23 and the 0.20 result were accepted.

Any idea why this would be?

I've had exactly the same scenario, no idea why. However I suspect all current efforts are focused on the new app and validation related to that, and I can appreciate why that would be, as amongst other things, the new app will resolve the perpetual server crashes due to it not being able to keep up with the required file deletions.

Having achieved a large measure of stability with 0.23 and the validator change, I doubt much else will change until the new app rolls out this week.

Regards
Zy

With reference to Workunit 90777892:

Three results were apparently received from HD5xxx class ATI boards: one from a 32-bit platform running stock version 0.23, one from a 64-bit platform also running version 0.23, and one from an anonymous 64-bit platform running version 0.20. I would have thought the two 0.23 versions would form a quorum but they apparently did not. The first version 0.23 result (mine) was rejected while the second 0.23 and the 0.20 result were accepted.

Any idea why this would be?

I've had exactly the same scenario, no idea why. However I suspect all current efforts are focused on the new app and validation related to that, and I can appreciate why that would be, as amongst other things, the new app will resolve the perpetual server crashes due to it not being able to keep up with the required file deletions.

Having achieved a large measure of stability with 0.23 and the validator change, I doubt much else will change until the new app rolls out this week.

Regards
Zy

Same for me too.I got a whole bunch of tasks where two 58xx (0.20b and 0.22) got validated against each other (!) and my result (4870, 0.23) was marked as invalid ...

So there's definetly still something wrong with the validator...

---

Join Support science! Joinc Team BOINC United now!

Can you really call that a problem with the validator? It seems to be doing its job correctly - it's the older applications that mess things up. Pushing out the new, not backwards compatible applications should fix this, but that doesn't mean the validator is broken. Unless I'm misunderstanding you.

Can you really call that a problem with the validator? It seems to be doing its job correctly - it's the older applications that mess things up. Pushing out the new, not backwards compatible applications should fix this, but that doesn't mean the validator is broken. Unless I'm misunderstanding you.

I guess Crunch3r thinks the validator should also check the combination of GPU and application version. If a HD5800 GPU returns a result calculated with anything prior to 0.23, it should be rejected because it is a known fact that this result is not reliable.
It would greatly reduce the number of results wrongly declared as invalid (and wrongly declared as valid, too!) and at the same time increase the pressure on HD5800 owners to update to 0.23.

I guess Crunch3r thinks the validator should also check the combination of GPU and application version. If a HD5800 GPU returns a result calculated with anything prior to 0.23, it should be rejected because it is a known fact that this result is not reliable.
It would greatly reduce the number of results wrongly declared as invalid (and wrongly declared as valid, too!) and at the same time increase the pressure on HD5800 owners to update to 0.23.

Yes, your're right about that. Should be easy to implement a app version check server side... since each work request no matther if "stock" or anonymous contains a version tag <version_num>22</version_num>.

FWIW, the best way to handle the sittuation would have been to introcude a new app like it is planed for milkyway3. That would have prevented sending out WUs to hosts runing the faulty apps in the first place since everyone would have been forced to upgrade...

---

Join Support science! Joinc Team BOINC United now!

Yes, your're right about that. Should be easy to implement a app version check server side... since each work request no matther if "stock" or anonymous contains a version tag <version_num>22</version_num>.

In another post, Travis said he tried that and it just caused the server to crash more often.

I guess Crunch3r thinks the validator should also check the combination of GPU and application version. If a HD5800 GPU returns a result calculated with anything prior to 0.23, it should be rejected because it is a known fact that this result is not reliable.
It would greatly reduce the number of results wrongly declared as invalid (and wrongly declared as valid, too!) and at the same time increase the pressure on HD5800 owners to update to 0.23.

Yes, your're right about that. Should be easy to implement a app version check server side... since each work request no matther if "stock" or anonymous contains a version tag <version_num>22</version_num>.

FWIW, the best way to handle the sittuation would have been to introcude a new app like it is planed for milkyway3. That would have prevented sending out WUs to hosts runing the faulty apps in the first place since everyone would have been forced to upgrade...

Absoluthly. I think it shows a bad atetude to let people continue to produse good results that still will be marked as 'Invalid' and wasted.
I can't understand why it is more importent to let the validator running than that it is working correct.

Absoluthly. I think it shows a bad atetude to let people continue to produse good results that still will be marked as 'Invalid' and wasted.
I can't understand why it is more importent to let the validator running than that it is working correct.

Well if the validator is crashing every two hours, or unable to keep up with the stream of workunits; it's going to effect a lot more people (and a lot less work is going to be done). Right now the number of invalid results is < 5%; and I think we've reached critical mass so that the vast majority of the ones being flagged as invalid now are actually invalid.

---

Absoluthly. I think it shows a bad atetude to let people continue to produse good results that still will be marked as 'Invalid' and wasted.
I can't understand why it is more importent to let the validator running than that it is working correct.

Well if the validator is crashing every two hours, or unable to keep up with the stream of workunits; it's going to effect a lot more people (and a lot less work is going to be done). Right now the number of invalid results is < 5%; and I think we've reached critical mass so that the vast majority of the ones being flagged as invalid now are actually invalid.

Based on the information in this thread would you say that the results
that are marked as 'Valid' really IS valid?
Is the validator also checking that the correct apps has ben used?