It would appear that in this case you have received a resent work unit as the first person to get that work unit was slow getting it back.
You only took a day to return the work unit.
Unfortunately the first person to get this work unit was able to return it (even if it had gone past deadline) before you were able to return yours (by about 2 hours).
This means that they still get the credit as they returned it first.
If you had of beaten the other person then you would have gotten the credit and they would have received zero.
been at it a week. put in half a dozen work units. haven't seen one point of credit. give me two logically sound reasons why I should continue with this nonsense. i don't mind helping out, but you are the ones offering to hand out credits for work done. there are other projects equally deserving of my time. if i don't see anything real soon . . . you can crunch it yourself.
____________
been at it a week. put in half a dozen work units. haven't seen one point of credit. give me two logically sound reasons why I should continue with this nonsense. i don't mind helping out, but you are the ones offering to hand out credits for work done. there are other projects equally deserving of my time. if i don't see anything real soon . . . you can crunch it yourself.
G'Day Carmine,
I have seen this post late so when I checked your work units to see if I could see a reason for the problems they had already been purged.
You are only now showing two work units in progress, one issued on the 27/4/10 and the other on the 1/5/10.
We will have to wait till they are returned to see what the issue is.
Sorry could not be of more help (I am only a volunteer not part of the project team).
____________
Conan
Let me get this straight Only the first person who returns a WU will get credit for it.
And The Project does allow WU's that are past there deadline
So this Project does not use redundancy to check for errors
Conan
Let me get this straight Only the first person who returns a WU will get credit for it.
And The Project does allow WU's that are past there deadline
So this Project does not use redundancy to check for errors
G'Day there laurenu2,
That's the way I understand it and it is the way it has been working.
Not really a project issue as it is built into Boinc. It can be modified by the project so it does not happen (at least I think it can).
If a WU is sent out and not returned by the WU's date of return (it's deadline), another is sent out so that quorum can be met.
If the first one that was sent out then completes and is then returned after the deadline it is still deemed valid if it is the first one back.
On a minimum quorum of 1 this will result in the second WU being given zero even though returned within deadline. This can still happen with quorums that are greater than 1 as well.
Some projects don't worry about the deadline, that is just a Boinc thing to help the manager work out how to allocate resources to the projects that you run.
The Lattice Project has a lot of WU's at the moment that are going past deadline and so another WU is being sent out. However the admin for that project has decided that the deadline does not matter and all work units that are sent out and returned will be granted credit.
Climate Prediction is another project that does not worry about deadlines or if more than one WU is returned out of the same batch, all get credit.
But it is basically the way Boinc is set up.
I believe that if a second or third or what ever number of WU's have been sent out then all should get credit, mainly because people are going to start checking to see if they have a resent work unit or a new one, if resent and there is a chance of the first person returning the work unit then they may just abort the work unit and get a new one rather than get no credit for returning the resent WU back.
____________
Thank you Conan for helping out with this question. It is indeed as you said. Specifically for Docking, we modified the transitioner daemon so that even if a time-out, error, or client disconnection occurs we don't send a second replica. This is because in order to assign credits as fast as possible, we don't use replication and this condition was causing that second or third replicas were not assigned credits. Now, to check errors we have a postprocessing phase where results that do not make sense are set aside and they do not interfere with the good computation. So far this technique is working well and we get very good accuracy of our results.
