> I suppose if we are adjusting DCF in the next go rounds then I will need > to pay attention to it ...
As it happens, here's one I _didn't_ prepare earlier - happened live just as I read your mail. http://img524.imageshack.us/img524/2865/setidcfeffect.png SETI has been sending out a lot lof VLAR work recently, and because I've been switching it to the CPU queue, that queue is quite full. It has also been reported that VHAR (short running, short deadline) work is processed more efficiently on the CPU - SETI's 30-second CUDA startup is a big part of a 6-minute runtime at VHAR on this host - so I've been switching those too. Short deadline, large cache - BOINC is a bit 'edgy' just at the moment. Hence the situation in the screenshot. The 24:45 CUDA task ready to report took much longer than expected - 15 minutes would be par for the fpops_est. So, when it finished 2:37 before the grab, DCF bumped up, ***all** SETI queue estimates jumped, and a new set of tasks was started in High Priority. Twenty minutes later, and it's all over: http://img17.imageshack.us/img17/2523/setidcfeffectover.png Five more normal completions have brought DCF down again - look at the estimates on the 01 May deadline tasks just below the four now ready to report: down from 33:13 to 28:08 This also shows the other effect Paul and I have been reporting - these CPU tasks would have finished in well under 20 minutes each if run singly against work from other projects on the other cores - it should be under 17 minutes, like http://setiathome.berkeley.edu/result.php?resultid=1211962928 from the same host this morning.(1008.25 CPU seconds). _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
