Tuberculosis project

[laurenu2]

OK I will go suck some other project Dry until RNA is ready

[Michael H.W. Weber]

The programmers are working hard to find a way of checkpointing (by the use of a Linux VM if I remember correctly), however the soulution they implemented so far works on Linux OS only.

A bit more precisely, current checkpointing works only on Linx x86 machines, not x64. Due to the comparably short run times, for the latest Mtb project, checkpointing is not really essential.

Michael.

[rilian]

crunching a win32 WU that has estimated runtime on reference system 4d 21h 53m 8s (424388 s)

so far 4:30 and 7%

btw, laurenu2, you are my wingman on this WU. hope you will claim much credits and we'll get the bank

[cisf]

i;ve noticed that the estimated time reported by boinc is crap. Ussually way overestimated. (and the "estimated runtime on reference system" for this project, it used to be accurate) http://www.rnaworld.de/rnaworld/workuni ... uid=610537

i took a task and start it localy (./cmsearch cmfile in), and the estimates were the times that the boinc task acctualy finished in. So maybe a boinc issue ?

[MReed]

Corect me if I'm wrong but I think that problem is pretty well known:

The predictions by the projects servers (or whatever computer does those predictions) are part of a miniseries of computation. Therefore the predictiontimes are firstly for this hardware-configuration and secondly they can be slightly off - so if BOINC detects a variance between the time predicted and the time which was actually needed for a specific WU, then the software automatically attempts to correct that mistake (you've heard of the task correction factor).

That means, if you got a pretty long WU the time needed might have been underestimated and therefore the task correction factor grew. If you get then some short WUs that factor is applied to the predicted time, resulting in way longer runtimes shown by BOINC.

[rilian]

MReed, i know

i just notice that not all WUs fall into 1-10 hours runtime , as said above

[MReed]

Well no offence there rilian, I merely tried to explain that matter to cisf

[yoyo]

Corect me if I'm wrong but I think that problem is pretty well known:

The predictions by the projects servers (or whatever computer does those predictions) are part of a miniseries of computation. Therefore the predictiontimes are firstly for this hardware-configuration and secondly they can be slightly off - so if BOINC detects a variance between the time predicted and the time which was actually needed for a specific WU, then the software automatically attempts to correct that mistake (you've heard of the task correction factor).

That means, if you got a pretty long WU the time needed might have been underestimated and therefore the task correction factor grew. If you get then some short WUs that factor is applied to the predicted time, resulting in way longer runtimes shown by BOINC.

This is called DCF (duration correction factor). In newer Boinc versions click in the project tab on RNA World and then on the left side on the button properties (I hop this is the right name in the engl. version). There you see the DCF, means the value with which Boinc multiplies the estimates. Idealy it should be 1.

MReed, you are not totaly right. The estimates are not depending on the HW. To be exact, it is like that:
- forecast runs on the project server and returns the time which is probably needed.
- this time is multiplied by the FLOP/s of the server
- so the WU has assigned FLOPS which are needed
- the Boinc client divides it by it's own FLOP/s
- the result is the time which is needed on this special client
- this time is further multiplied with DCF

yoyo

[MReed]

Well, yoyo, I'll try to keep that in mind

[[FVG] bax]

This WU has something strange (I apologize if this item was already discussed)

http://www.rnaworld.de/rnaworld/workuni ... uid=559333

Minimum quorum = 2, Initial replication = 3
but 1st WU was sent at 9 Apr 2010 16:03:20 UTC (returned 10 Apr 2010), 2nd at 14 Apr 2010 17:28:50 UTC so there is not a real cuncurrent "initial replication".

more: 2nd WU was returned at 15 Apr 2010 1:14:34 UTC, 4 minutes later the 3rd WU was sent out and again 3 minutes later the 3rd WU was retired cause "redundant result", maybe because validator stated that 1st and 2nd WUs were correct

isn't it a strange behaviour?


P.S. this is not the only WU with such kind of behaviour

[yoyo]

The transitioner was a bit behind the results, thin it was 1 or 2h. Seems that in this time the 3rd was sent out. As the transitioner reached this wu, it was validated and the 3rd result was canceled.
yoyo

[rilian]

Estimations failed, WU finished in 13 hours