My A64 2800 just crunched three S5 units at about 9 hours each... Let's all hope that Akos can bring out an optimized version soon to cut down on time.
My A64 2800 just crunched three S5 units at about 9 hours each... Let's all hope that Akos can bring out an optimized version soon to cut down on time.
14 hrs 42 mins for first S5 WU. This on an AMD XP 1600+ system.
Got 138.83 credit...works out to approx. 9.45 CS/hr
I can live with that. Mine has yet to be validated. Interesting that your claim (the lower of the two) was also what was granted.
For S5, the granted credit is decided before wu is issued to computers, and the Validator uses this pre-generated granted credit and doesn't look on that the different claims are.
The application also gets the same info, and tries to pass-this along back to server, so the claimed credit most of the time is the same as granted.
But, for the application to correctly pass-on the info, you need to run BOINC-client v5.2.6 or later, for the wu in question one user was using v5.2.2, and his claimed credit is therefore based on benchmark * cpu-time.
But in any case, it wouldn't have been any problem if one claimed zero and another 200, the Validator would still override this, and give granted 138.83 CS.
The most common behaviour in BOINC-projects, and the one method used in S4 and earlier, is:
Granted credit is decided at the same time wu has been validated:
1; If only 2 results passed validation, lowest claimed to all.
2; If 3 or more, remove highest and lowest claimed, and average the rest.
Any later-returned results that also passes validation, gets the same granted credit, no re-calculation is done.
As for the reason to never use the highest-claim and average, this is so someone trying to cheat won't get any benefit from this as long as not atleast 2 crunching the same wu tries to cheat.
Anyway, since Einstein@home now have changed to fixed credit per wu, just like CPDN is using, it's not possible to cheat by artificially inflated credit-claims here any longer. :)
"I make so many mistakes. But then just think of all the mistakes I don't make, although I might."
14 hrs 42 mins for first S5 WU. This on an AMD XP 1600+ system.
Got 138.83 credit...works out to approx. 9.45 CS/hr
I can live with that. Mine has yet to be validated. Interesting that your claim (the lower of the two) was also what was granted.
For S5, the granted credit is decided before wu is issued to computers, and the Validator uses this pre-generated granted credit and doesn't look on that the different claims are.
I understand that. I meant I thought it was interesting that the predetermined credit was exactly what he asked for.
14 hrs 42 mins for first S5 WU. This on an AMD XP 1600+ system.
Got 138.83 credit...works out to approx. 9.45 CS/hr
I can live with that. Mine has yet to be validated. Interesting that your claim (the lower of the two) was also what was granted.
For S5, the granted credit is decided before wu is issued to computers, and the Validator uses this pre-generated granted credit and doesn't look on that the different claims are.
I understand that. I meant I thought it was interesting that the predetermined credit was exactly what he asked for.
I understand that. I meant I thought it was interesting that the predetermined credit was exactly what he asked for.
Looking a little closer, example WUfpops=1.87236e+13 is part of wu's command-line that is executed by einstein-application then crunches the wu, and as long as you're running BOINC-client v5.2.6 or later this is passed-back to server as fpops_cumulative=1.87236e+13
Server-side, the Scheduling-server if there is any reported fpops_cumulative, uses this instead of benchmark * cpu-time when deciding claimed credit, by dividing by 8.64e11, meaning 1.87236e13 / 8.64e11 = 21.67 Cobblestones.
Validator reads the same WUfpops when deciding granted credit, meaning as long as someone runs BOINC-client v5.2.6 or later their claimed credit will be the same as granted credit.
Ok, there is a small variation in granted, likely since Validator gets the full WUfpops, while client only gets 6 numbers. This gives a difference in the order of 0.0001%...
"I make so many mistakes. But then just think of all the mistakes I don't make, although I might."
My A64 2800 just crunched
)
My A64 2800 just crunched three S5 units at about 9 hours each... Let's all hope that Akos can bring out an optimized version soon to cut down on time.
RE: My A64 2800 just
)
Have a look at this post: http://einsteinathome.org/goto/comment/37567
RE: RE: 14 hrs 42 mins
)
For S5, the granted credit is decided before wu is issued to computers, and the Validator uses this pre-generated granted credit and doesn't look on that the different claims are.
The application also gets the same info, and tries to pass-this along back to server, so the claimed credit most of the time is the same as granted.
But, for the application to correctly pass-on the info, you need to run BOINC-client v5.2.6 or later, for the wu in question one user was using v5.2.2, and his claimed credit is therefore based on benchmark * cpu-time.
But in any case, it wouldn't have been any problem if one claimed zero and another 200, the Validator would still override this, and give granted 138.83 CS.
The most common behaviour in BOINC-projects, and the one method used in S4 and earlier, is:
Granted credit is decided at the same time wu has been validated:
1; If only 2 results passed validation, lowest claimed to all.
2; If 3 or more, remove highest and lowest claimed, and average the rest.
Any later-returned results that also passes validation, gets the same granted credit, no re-calculation is done.
As for the reason to never use the highest-claim and average, this is so someone trying to cheat won't get any benefit from this as long as not atleast 2 crunching the same wu tries to cheat.
Anyway, since Einstein@home now have changed to fixed credit per wu, just like CPDN is using, it's not possible to cheat by artificially inflated credit-claims here any longer. :)
"I make so many mistakes. But then just think of all the mistakes I don't make, although I might."
RE: RE: RE: 14 hrs 42
)
I understand that. I meant I thought it was interesting that the predetermined credit was exactly what he asked for.
RE: RE: RE: RE: 14
)
This is only because of rounding:
Claimed credit: 138.834490740741
Granted credit: 138.834968581483
So actually, I came out ahead by .00047+ CS
:-P
Seti Classic Final Total: 11446 WU.
RE: I understand that. I
)
Looking a little closer, example WUfpops=1.87236e+13 is part of wu's command-line that is executed by einstein-application then crunches the wu, and as long as you're running BOINC-client v5.2.6 or later this is passed-back to server as fpops_cumulative=1.87236e+13
Server-side, the Scheduling-server if there is any reported fpops_cumulative, uses this instead of benchmark * cpu-time when deciding claimed credit, by dividing by 8.64e11, meaning 1.87236e13 / 8.64e11 = 21.67 Cobblestones.
Validator reads the same WUfpops when deciding granted credit, meaning as long as someone runs BOINC-client v5.2.6 or later their claimed credit will be the same as granted credit.
Ok, there is a small variation in granted, likely since Validator gets the full WUfpops, while client only gets 6 numbers. This gives a difference in the order of 0.0001%...
"I make so many mistakes. But then just think of all the mistakes I don't make, although I might."
Mine are all slices off an H1
)
Mine are all slices off an H1 file. And all run in under one and a half hour on my P4 2.8GHz.
I should probably wait for a really slow big one. ;-)
We need Optomized
)
We need Optomized Einstein?
Does that mean your computer will do the work faster and get
equal or more credit than with the stock apps.?
Such as happens over at S@H?
RE: Mine are all slices off
)
Hi Jord,
I just finished what looks like a bigger one on my P4 3.0
It took 19 hours.
http://einsteinathome.org/workunit/9910537
RE: We need Optomized
)
Yes