End of S5RI near?
22 Mar 2007 20:04:05 UTC
Topic 192545
(moderation:
Hello.
Then I lokk into the server status page, I can read "valid last week 1,069,217". "Work still remaining" for S5RI is 2,270,915 units. Can you say, that this run is ended in 2 weeks?
And what about the S5R2? Will it start with no break between?
MfG
Sven S. aus G.
End of S5RI near?
)
Not quite. The 'work remaining' is measured in workunits, but the 'valid last week' is measured in results. There are two results for every workunit, so it'll take twice as long as your estimate - or close to the 30.9 days shown as an estimate under the 'work remaining' figure.
Bit I'd like to hear about plans for S5R2, too!
We're frantically working on
)
We're frantically working on S5R2 setup and software to make it run well before we run out of S5RI work.
BM
BM
Thanks, Bernd.
)
Thanks, Bernd.
Sounds good. Thanks for
)
Sounds good. Thanks for keeping us informed. Is there an estimate yet as to how big the workunits will be? I've got a P3 and an "office" (meaning lame ^^) notebook attached here and hope they won't take ages to complete a WU ;-)
RE: Is there an estimate
)
Not yet. It hadn't been decided yet, and the decision requires quite some thought.
One aspect may illustrate that:
The new code hasn't the level of optimization than the one currently running has, so the Apps will become faster during the run (at least I intend to make them). CPUs that are already faster will benefit even more from optimized code than older, slow ones. The average computing power will also increase over the time of a run. So the same amount of "work" will take longer at the beginning than at the end of a run. As we have seen at the end of S5R1, (BOINC on) our servers can only handle a limited load, so we can't set up a workunit size that at the end of the run floods our servers with results from fast machines. Thus we have to anticipate the time a future machine will take with a future version of our code, and together with an estimate of the number of hosts (and, yes, some safety margin) this will give us a lower bound for the size of a workunit - we can't make it shorter than that. It might be somewhat irritating, but for the shortest possible duration we have to think about the fastest machines, not the slowest.
There are some more factors to take into account; this is everything else but an arbitrary choice we have.
BM
BM
That's of course
)
That's of course understandable. Of course you have to take all that into account. Thanks for getting back so quickly and for the informative post; it's always great to get some technical background knowledge.
So, I guess I'll just have to wait and see, if it's necessary I'll just have to let my older boxes take their time for the WUs during the next run.
RE: ...The new code hasn't
)
This begs the question of "Why Not?"
Is Akos Fekete yet connected with the project or have you parted?
Run times of around 6 - 8 hours are good for me on my P4 HT 3 GHz. For reference the current S5RI tasks are running 5.5 hours. But since checkpointing is frequent and predictable (unlike Rosetta which check points randomly when a decoy is generated) I don't really care how long the tasks are, frankly.
RE: RE: ...The new code
)
The code that runs on Einstein@Home today is the result of years of use, bug fixing and optimization. The one we're working on for S5R2 is all new and has never been used before.
Assembler coding is tedious, time-consuming and error-prone. It's ok to code some tiny bits in assembler when you have some (less optimized) code or program to compare it with of which you are absolutely sure that it reliably does what you want and it won't change anymore. If you can't be sure of this, you'll end up trashing two weeks of work every day. We're still working on that "reference code".
Akos has agreed to help us in optimizing the S5R2 code.
The Apps are designed to allow checkpointing after every "sky position", which should work well with the default "write to disk at most..." setting of once a minute. The faster the machine, the smaller you can make that interval, if it finishes a sky position every second, you should be able to checkpoint every 10 secons or so (resuming from a checkpoint takes much more than a second).
BM
BM
But it would still put more
)
But it would still put more strain on the hard disk to checkpoint more frequently iirc, so I'd rather not risk it personally...
RE: But it would still put
)
I wouldn't worry about that. :)