Sek, my initial reaction is that you're flirting with danger using that. It would seem to be all too easy to pull down more work than you can complete by the deadline. With the way the computational_deadline affects if you get new work, I suspect that what you would see in practice is that you'd get that factor much more work when the computational deadline allowed you to get new work. That would tend to bunch up your report deadlines where if you miss that on one, you'd miss instead on several.

Depends on the size of the task buffer. At 2,5 days and a deadline of 7 days, it should not put u in harms way with a 30 WU per core / per day limit. It's one of those manual emergency settings: U add it, u manage it!

Actually, when I found the DCF fix in 5.8.9 that I mentioned earlier in this thread, I upgraded to that. With the new scheduler and work fetch policy in 5.8.x, using that option seems to be a lot riskier to me, even if it is not new. It appears that all you need is one WU beyond the computational deadline to stop you from getting any new work until it completes. There is NOT any easy way of identifying that WU either. Normally, you'd expect it to be the oldest WU but with WCG's multiple projects, I'm not so sure you can count on that. I'd like to be wrong though and, given WCG's seven day reporting deadline, be able to say that you don't want any incomplete WU's received more than three days ago. Taking the new scheduler and work fetch policy, combining that with the desire to maintain a queue to avoid any crunching downtime, it would seem like the ideal would be that each time you return X hours of work, you get X hours of new work. If a WU in your queue hits the computational deadline and new work fetch gets suspended, it would seem that you have a good probability that, by the time that WU completes, another WU in the queue behind it will also be in the same state so work fetch will remain suspended until you clear out your queue. At that point, it will then fill back up but now you have Z days worth of work all due at the same time in seven days. Just the opposite of the evenly spread distribution of report deadlines that you ideally want. I'm still sorting this all out but if there are bugs in the scheduler, those could make the situation even worse. Trouble is, when I experiement with some part of my queue, I have to let that part complete before I can try again. Twice now, I have seen BOINC Manager start a 'Ready to run' WU over an earlier "Waiting to run" nee preempted WU. I've also seen two instances where a WU was in Running status but actually BOINC was idle and one instance where I had TWO WU's in Running status on a single core machine. Hopefully, I'll be able to get a point where I have a scenario of steps A, B, and C give X where X does not appear to be a correct state and it can be determined if that is a bug or not.

There are so many permutations and possibilities that it cant be said in absolute, but can definitely say: Never missed a deadline when on site.

Anyway i like experimenting without changing client every 5 minutes so set this variable in the CC_config.xml forced BOINC to read it and let it sit for 48 hours. To back up a bit: This machine has been on 5.8.8 for weeks and now on 5.8.9 for afair part of the week, buffer on 2.5, permanent connection and an ONLY FAAH diet with highly variable length and operating on 10 in 10 out and not fetching work either until the very last job is started or even 1 core was idling. No other projects, 100% WCG.

Now after 2 days and another 17 done, BOINC woke up and send a message to fetch 4.04 million seconds of work and got 10 more.....first time in a month 13 FAAH's in buffer, which with length dependence will finish by Tuesday morning - Where the deadline is the 19th!

DCF is 1.3 and all other client state readings indicate normality including the fractions (). Given that the single core p4 behaves normal and trickles, i have a stronger believe that on a C2D where 1 core is fully dedicated to crunching and the other 'used' quite actively besides crunching, it forming a problem for the new WFP algorithms. The fetch problems only started with the 5.8 development versions and persist thru 5.8.9

BOINCview, my beloved crunching companion computed it got 1d23h05m36s buffer this moment after just sending off, yes it was a long one again 8:05 hr FAAH. The next one finishing will be under 6! Figure what that does to the DCF :O (advise not to use a crowbar to open up my mouth)

Luctor et Emergo (i struggle and will conquer)

I'm cheering you guys on!

Diana G.