// DBOINCP-300: added node comment count condition in order to get Preview working ?>
Anonymous
23 Jan 2008 17:39:36 UTC
Topic 13644
(moderation:
)
Actually news, but I didn't come to write the details yet. We found we had to break the current run in two parts at 800Hz frequency. The display shows the work remaining below 800Hz. We'll have set up the upper half in a few days.
I noticed all the WUs i had above 800 gives way too much credit, will future WUs in that range give lower credits?
Apn unexpected side-effect of the problems we have found with the >=800Hz WUs is that they run shorter as intended. The new ones will get the same credit, but run noticeably longer.
The data files currently on Einstein@home of 800Hz and above (h1_0800.0_S5R2* / l1_0800.0_S5R2*) are wrong. While we are generating the correct ones, we stopped generating workunits for 800Hz and above.
We intend to let the some thousand WUs that point to the wrong files that are already in the database simply run out. The ones on the boundary (that have 0799.5 files as well as 0800.0) will error out just at the beginning when trying to read the files ("error in SFT sequence"), with no CPU time wasted. The ones above 800Hz that are already in the database will run shorter as the assigned credit would suggest, because the run-time and this the credit was estimated based on correct datafiles. If we would simply cancel these workunits, people that already have completed such a task would get no credit at all for this, so I decided to be rather too generous and let them run.
The current WU generator will only generate new WUs below 800Hz. There are ~300,000 left to be generated, which should be work for the project for about a week in total. During that time we will generate correct data files and set up a new WU generator for the work of 800Hz and above.
So the second half run of S5R3 (currently internally called S5R3b) should start early next week. The new Tasks will run as long as estimated and thus will get the same credit we currently give to the ones with the same base-frequency (but wrong data files).
Brian, we are considering your proposal to extend the deadline for these new WUs.
Anyway, as for the boundary tasks, do you know if all of those have already been distributed? Since they fail very quickly, any host that gets them will likely be driven down to only 1/day quota...
You're right, I cancelled the workunits, which means that no new tasks should be generated for them. For the few dozen tasks that have already been generated for these in the DB I'm afraid I won't be able to do anything (without risking DB inconsistencies).
Update: We started to "drain" the current S5R3a workunit generator, i.e. it will generate all the workunits below ~799Hz that have not yet been generated, put them into the database and then terminate.
You should see a fast decrease in the "Work remaining", a fast increase in the "Workunits in database" and "Workunits with no canonical result" values on the Server status page, and finally find the "Einstein S5R3 generator" "Not running" any more.
This will allow us to start the new "S5R3b" workunit generator some time tomorrow. Hopefully everything goes smooth enough that people not reading the forums won't even notice that there is a transition. The Apps (Beta-, power- and standard Apps) will stay the same, so no need to do something there.
We started to send out the first (few hundred) "upper-half" S5R3 tasks for testing. For the curious: The task names end in "S5R3b", and the data files in "S5R3". The Delay Bound ("deadline") has been increased to 18 days.
Sudden lurch in remaining work display
)
Apn unexpected side-effect of the problems we have found with the >=800Hz WUs is that they run shorter as intended. The new ones will get the same credit, but run noticeably longer.
BM
BM
The data files currently on
)
The data files currently on Einstein@home of 800Hz and above (h1_0800.0_S5R2* / l1_0800.0_S5R2*) are wrong. While we are generating the correct ones, we stopped generating workunits for 800Hz and above.
We intend to let the some thousand WUs that point to the wrong files that are already in the database simply run out. The ones on the boundary (that have 0799.5 files as well as 0800.0) will error out just at the beginning when trying to read the files ("error in SFT sequence"), with no CPU time wasted. The ones above 800Hz that are already in the database will run shorter as the assigned credit would suggest, because the run-time and this the credit was estimated based on correct datafiles. If we would simply cancel these workunits, people that already have completed such a task would get no credit at all for this, so I decided to be rather too generous and let them run.
The current WU generator will only generate new WUs below 800Hz. There are ~300,000 left to be generated, which should be work for the project for about a week in total. During that time we will generate correct data files and set up a new WU generator for the work of 800Hz and above.
So the second half run of S5R3 (currently internally called S5R3b) should start early next week. The new Tasks will run as long as estimated and thus will get the same credit we currently give to the ones with the same base-frequency (but wrong data files).
Brian, we are considering your proposal to extend the deadline for these new WUs.
BM
BM
RE: Current app will handle
)
The new workunits will reference the same Apps. No change there.
BM
BM
RE: Anyway, as for the
)
You're right, I cancelled the workunits, which means that no new tasks should be generated for them. For the few dozen tasks that have already been generated for these in the DB I'm afraid I won't be able to do anything (without risking DB inconsistencies).
BM
BM
Update: We started to "drain"
)
Update: We started to "drain" the current S5R3a workunit generator, i.e. it will generate all the workunits below ~799Hz that have not yet been generated, put them into the database and then terminate.
You should see a fast decrease in the "Work remaining", a fast increase in the "Workunits in database" and "Workunits with no canonical result" values on the Server status page, and finally find the "Einstein S5R3 generator" "Not running" any more.
This will allow us to start the new "S5R3b" workunit generator some time tomorrow. Hopefully everything goes smooth enough that people not reading the forums won't even notice that there is a transition. The Apps (Beta-, power- and standard Apps) will stay the same, so no need to do something there.
BM
BM
We started to send out the
)
We started to send out the first (few hundred) "upper-half" S5R3 tasks for testing. For the curious: The task names end in "S5R3b", and the data files in "S5R3". The Delay Bound ("deadline") has been increased to 18 days.
BM
BM