1666 hours projected for a GRP #2 1.09 task
22 Jun 2013 1:25:27 UTC
Topic 197013
(moderation:
I've been following the dialog re increased run times. On my machine the GRP tasks increased from ~1.5 hours to ~17 - 20 hours. But the next task to be undertaken projects 1666 hours will be needed. I don't believe this, but I don't know what to do with it. If this is a case of GIGO I should abort it now. Otherwise it might be interesting to see what happens.
I would like advice from a mod, please. THX (but not 1138).;P
Steve
"Remember, nothing that's good works by itself, just to please you. You have to make the damn thing work." Thomas A. Edison
1666 hours projected for a GRP #2 1.09 task
)
I'd say let it run, that could be good science. I would expect it to finish in your sub 20 hr. range.
In your case it doesn't look
)
In your case it doesn't look like you are going to get bit by the exceeded time limit problem, so the ridiculous time estimate isn't a problem per se.
However the unintended consequence of running them will be it will cause the DCF for EAH to balloon, so BOINC will draw less work from the project (as well as run in 'High Priority mode') for a while until it can work it back down to it 'normal' range.
HTH
Since several days the
)
Since several days the estimated execution time for the tasks is not correct.
At this moment eg I see on my Windows computer:
task: GPR #2 1.09
progress: 26,81%
time elapsed: 6:12
time still to go: 201:47 (???)
task: GPR #2 1.09
progress: 33,63%
time elapsed: 7:48
time still to go: 191:59 (???)
task: BRPS (GPU task)
progress: 42,68%
time elapsed: 6:20
time still to go: 51:18 (???)
What's going on?
RE: In your case it doesn't
)
You're probably right about the DCF. At this time the task I referred to is 80.829% done, with 543:40:58 remaining and 11:44:06 elapsed, and it is the task running in high priority. A couple of years ago I tried in vain to change the DCF manually, using the procedure of totally shutting down BOINC first. Repeated attempts were fruitless, so now I just ignore the DCF.
Steve
"Remember, nothing that's good works by itself, just to please you. You have to make the damn thing work." Thomas A. Edison
RE: What's going
)
Several things probably but you will need to read this thread in order to understand the issue. It's not just that there has been a change to the size of FGRP2 tasks and that some early ones of the new larger size went out with a wrong flops estimate. It's also to do with the fact that there is only a single DCF (Duration Correction Factor) for a project so if the various science apps perform differently (ie some run faster than the estimate and some run slower) then you can have a DCF 'see-sawing' effect that can really screw up estimated crunch times.
I have seen exactly what you are experiencing on some of my hosts. The important thing is to ignore the unrealistic estimates as the tasks will crunch for the correct amount of time in the end. BOINC is quite likely to panic (Hi Prio mode), particularly if your cache settings are too large. Depending on your version of BOINC, panic mode may cause tasks to be preempted and new ones to start in their place and I've seen this `snowball' so I'm quite leery of panic mode (unless it's genuinely needed).
It helps to temporarily reduce cache settings until BOINC reduces the DCF to more normal values. You can also get rid of panic mode by `suspending' a slab of the tasks causing it, temporarily. Just don't forget to 'resume' them later when the panic has passed.
BOINC will (largely) fix the crazy estimates over time so you need to be patient. It may take quite a while for the DCF to be reduced to more usual levels due to the nature of the algorithm inside the client that does this. You can manually 'fix' things by editing of the state file but it's not recommended unless you know precisely what you are doing.
Cheers,
Gary.
Gary, thanks for your clear
)
Gary, thanks for your clear answer: I'll be patient. Moreover I'm glad that the meaning of the abbreviation DCF is now clear to me :-)
Cheers,
Herman