So if my credit per WU goes 222 cobblestones, it means it should be around 222 as well....? (Fingers crossed)
Not quite sure what you mean. There will still be a significant gap between claimed credit and granted credit (claimed credit is just ignored by E@H anyway, credit is fixed at the server level).
In S5R1..S5R4 all WU of a certain frequency range got you the exact same credit, like, say, 222 credits. However, some of them would take (say) 10 hours to complete and others (say) 12 hours.
With S5R5, workunits are shorter, but the relative variation is expected to be greater, so, say, one WU would finish in 6 hours (for say 111 credits) and the other in maybe 3.5 hours.
To award the same credits to WUs with such a big variation is probably not very well received by users, even if the average credits/h would (over a long time) be the same.
So an attempt was made to actually try to award credits according to the complexity of the WUs. Longer WUs will get more credits and shorter ones less.
This can only be an approximation, and may need some adjustments after seeing how well this works out for a) different WU frequency ranges and b) different hardware. For the "theory" of the runtime variations, see the different threads on performance measurement and the "ready reckoner" here in this forum that provided the input for this approximation. (Gary, Mike, Richard Haselgrove and archae86 provided a lot of insight and data there).
Luckily both my systems returned their latest tasks just today and BOINC was giving the CPU time back to the other projects. So in eager anticipation I've put Einstein on NNT on both systems and in a bit I'll remove the app_info.xml files for the various Power Apps they run, so that when I re-allow work tomorrow, I'll only have to do a reset prior to that and hope to sit back and await the new downloads. ;-)
The S5R4 workunit generator (WUG) has been stopped and the S5R5 one been started instead. S5R5 has officially been launched.
The server status page has been updated. BTW ABP1 (currently under "previous searches") lists the workunits in the active database from the Arecibo Binary Pulsar search; currently the ones remaining from the test in December. The time estimations for S5R5 look a bit absurd, but that usually settles for some reasonable value after the WUG ran for a few days.
The runtimes of S5R5 tasks should be half the one you know from S5R4, but don't judge this after a few tasks - the runtime variation between different tasks of the same frequency is larger in S5R5.
We intend to keep the credit level (credits per CPU hour) the same as in S5R4, but due to the rather short internal testing we relied on some educated guessing. We think we got it pretty close, but might need to make some adjustment to that in a week or so.
And same here: got two S5R4 reissues. I think it'll depend on how many unsent results for your frequency range there were and how quickly you and your data file partners can pick up the old results. The oldest unsent result in database is now just less than 7 days old.
Yes, the S5R4 workunits will remain the majority for the next few days. We won't cancel them so people will get credit for them; this will also help our servers to cope with the transition.
13-Jan-09 19:58:36|Einstein@Home|Started download of einstein_S5R5_3.01_windows_intelx86_0.exe
13-Jan-09 19:58:37|Einstein@Home|Finished download of einstein_S5R5_3.01_windows_intelx86.exe
13-Jan-09 19:59:15|Einstein@Home|Started download of skygrid_0640Hz_S5R5.dat
13-Jan-09 19:59:17|Einstein@Home|Finished download of skygrid_0640Hz_S5R5.dat
So if my credit per WU goes
)
So if my credit per WU goes 222 cobblestones, it means it should be around 222 as well....? (Fingers crossed)
RE: So if my credit per WU
)
Not quite sure what you mean. There will still be a significant gap between claimed credit and granted credit (claimed credit is just ignored by E@H anyway, credit is fixed at the server level).
In S5R1..S5R4 all WU of a certain frequency range got you the exact same credit, like, say, 222 credits. However, some of them would take (say) 10 hours to complete and others (say) 12 hours.
With S5R5, workunits are shorter, but the relative variation is expected to be greater, so, say, one WU would finish in 6 hours (for say 111 credits) and the other in maybe 3.5 hours.
To award the same credits to WUs with such a big variation is probably not very well received by users, even if the average credits/h would (over a long time) be the same.
So an attempt was made to actually try to award credits according to the complexity of the WUs. Longer WUs will get more credits and shorter ones less.
This can only be an approximation, and may need some adjustments after seeing how well this works out for a) different WU frequency ranges and b) different hardware. For the "theory" of the runtime variations, see the different threads on performance measurement and the "ready reckoner" here in this forum that provided the input for this approximation. (Gary, Mike, Richard Haselgrove and archae86 provided a lot of insight and data there).
CU
Bikeman
Luckily both my systems
)
Luckily both my systems returned their latest tasks just today and BOINC was giving the CPU time back to the other projects. So in eager anticipation I've put Einstein on NNT on both systems and in a bit I'll remove the app_info.xml files for the various Power Apps they run, so that when I re-allow work tomorrow, I'll only have to do a reset prior to that and hope to sit back and await the new downloads. ;-)
The new applications are in
)
The new applications are in the pipe since yesterday afternoon. Now we only needs the new work for them. ;)
The S5R4 workunit generator
)
The S5R4 workunit generator (WUG) has been stopped and the S5R5 one been started instead. S5R5 has officially been launched.
The server status page has been updated. BTW ABP1 (currently under "previous searches") lists the workunits in the active database from the Arecibo Binary Pulsar search; currently the ones remaining from the test in December. The time estimations for S5R5 look a bit absurd, but that usually settles for some reasonable value after the WUG ran for a few days.
The runtimes of S5R5 tasks should be half the one you know from S5R4, but don't judge this after a few tasks - the runtime variation between different tasks of the same frequency is larger in S5R5.
We intend to keep the credit level (credits per CPU hour) the same as in S5R4, but due to the rather short internal testing we relied on some educated guessing. We think we got it pretty close, but might need to make some adjustment to that in a week or so.
BM
BM
RE: The S5R4 workunit
)
And so I allowed for some extra minutes between its launch and me re-allowing work. Got an S5R4 of course. ;-)
Yes, three hosts three times
)
Yes, three hosts three times re-allowing new work and got 3 times S5R4-units ;-)
And same here: got two S5R4
)
And same here: got two S5R4 reissues. I think it'll depend on how many unsent results for your frequency range there were and how quickly you and your data file partners can pick up the old results. The oldest unsent result in database is now just less than 7 days old.
The deadline is 14 days.
Yes, the S5R4 workunits will
)
Yes, the S5R4 workunits will remain the majority for the next few days. We won't cancel them so people will get credit for them; this will also help our servers to cope with the transition.
BM
BM
Go figure. My AMD got an S5R5
)
Go figure. My AMD got an S5R5 out-of-the-box.
13-Jan-09 19:58:36|Einstein@Home|Started download of einstein_S5R5_3.01_windows_intelx86_0.exe
13-Jan-09 19:58:37|Einstein@Home|Finished download of einstein_S5R5_3.01_windows_intelx86.exe
13-Jan-09 19:59:15|Einstein@Home|Started download of skygrid_0640Hz_S5R5.dat
13-Jan-09 19:59:17|Einstein@Home|Finished download of skygrid_0640Hz_S5R5.dat
Let's see how quickly it can rip through it. :-)