This host [CPU only] got this task on Friday. With a 3 day deadline on a 3.5/0.1 day cache. It went immediately into EDF, of course. When I investiagted why I'd gotten something that should not have made the deadline test I found something like 'estimated delay 0, deadline test skipped' for that task. A second of the same type was checked and summarly rejected - I got a BRP instead.
Unfortunately I missed out on keeping the server log for that workfetch.
According to some checkin around boinc 6.6 estimated delays are used for deadline acculations. A quick check of my sched_request files for various projects found that field was 0 for all of them, regardless of project cache. I've not had the time yet to check the code how that delay is calculated. Since this is the first time I've received a task that has a shorter deadline than the minimal cache I suspect minimal overall impact - but I do shut down over the weekend, so the 3.5 day setting is fairly realistic.
It might be a slight misconfiguration on Albert or I've found another bug...
So, when I received that task it had an estimate of 1:20 and was running and checkpointing nicely. It got to around 50% in something like 35 minutes so I assumed the estimate was fairly spot on and didn;t worry about the deadline any more. about two hours later I checked again on the task and to my extreme astonishment it had dropped back to around 4%. A quick check of stderr in the slot found it was doing skygrid 2/25, so 4% was a good fraction. Elapsed time was eventually 7 hours and I returned it in time, but I was left wondering why
a) I'd gotten the task in the first place and
b) how come its fraction completed dropped like that.
I suppose the crappy initial estimate is to be expected, but underestimating by 6x is suboptimal. David's new formula for calculating estimated time remaining doesn't really help there either.
Queen of Aliasses, wielder of the SETI rolling pin, Mistress of the red shoes, Guardian of the orange tree, Slayer of very small dragons.
This host [CPU only] got this
)
This host [CPU only] got this task on Friday. With a 3 day deadline on a 3.5/0.1 day cache. It went immediately into EDF, of course. When I investiagted why I'd gotten something that should not have made the deadline test I found something like 'estimated delay 0, deadline test skipped' for that task. A second of the same type was checked and summarly rejected - I got a BRP instead.
Unfortunately I missed out on keeping the server log for that workfetch.
According to some checkin around boinc 6.6 estimated delays are used for deadline acculations. A quick check of my sched_request files for various projects found that field was 0 for all of them, regardless of project cache. I've not had the time yet to check the code how that delay is calculated. Since this is the first time I've received a task that has a shorter deadline than the minimal cache I suspect minimal overall impact - but I do shut down over the weekend, so the 3.5 day setting is fairly realistic.
It might be a slight misconfiguration on Albert or I've found another bug...
So, when I received that task it had an estimate of 1:20 and was running and checkpointing nicely. It got to around 50% in something like 35 minutes so I assumed the estimate was fairly spot on and didn;t worry about the deadline any more. about two hours later I checked again on the task and to my extreme astonishment it had dropped back to around 4%. A quick check of stderr in the slot found it was doing skygrid 2/25, so 4% was a good fraction. Elapsed time was eventually 7 hours and I returned it in time, but I was left wondering why
a) I'd gotten the task in the first place and
b) how come its fraction completed dropped like that.
I suppose the crappy initial estimate is to be expected, but underestimating by 6x is suboptimal. David's new formula for calculating estimated time remaining doesn't really help there either.
Queen of Aliasses, wielder of the SETI rolling pin, Mistress of the red shoes, Guardian of the orange tree, Slayer of very small dragons.