I downloaded a Seti WU and a Climate Prediction WU about two weeks ago, and the Climate Prediction WU has got a lot more time than the Seti WU (each with \"100\" as the \"Resource Share\" value). Now the deadline is creeping up for the Seti WU (Sept 22) and it\'s only 50% done. Is Climate Prediction going to preempt it past the deadline?

If so, I think that\'s a bug that\'s going to render a lot of WU from all the other projects useless and needs to be fixed immediately. It\'s one thing to waste computer time donated to your project ironing out the bugs for your system; it\'s quite another to waste the computer time donated to other projects while fixing your problems.

Try downloading & running the latest version of BOINC, v4.09...

<a href="http://www.nmvs.dsl.pipex.com/"><img src="http://boinc.mundayweb.com/cpdn/stats.php?userID=6&amp;team=off&amp;trans=off"></a>

The problem isn't CPDN, it's BOINC. BOINC is what decides to preempt, not the project. So CPDN isn't wasting your time on other projects.

Yes, it's known that the early 4.xx releases have the astonishing ability to blow past deadlines. As uk_nick suggested, you could try BOINC 4.09, but I haven't read anywhere whether this issue has been fixed or not.

<a href="http://www.boinc.dk/index.php?page=user_statistics&amp;project=cpdn&amp;userid=355"><img border="0" height="80" src="http://355.cpdn.sig.boinc.dk?188"></a>

&gt; The problem isn't CPDN, it's BOINC. BOINC is what decides to preempt, not the
&gt; project. So CPDN isn't wasting your time on other projects.
&gt;
&gt; Yes, it's known that the early 4.xx releases have the astonishing ability to
&gt; blow past deadlines. As uk_nick suggested, you could try BOINC 4.09, but I
&gt; haven't read anywhere whether this issue has been fixed or not.
&gt;
The resource share usage is much better in 4.09, but it is still quite possible to blow past a deadline (in some cases without ever having started the WU).
<a href="http://www.boinc.dk/index.php?page=user_statistics&amp;project=cpdn&amp;userid=13"><img border="0" height="80" src="http://13.cpdn.sig.boinc.dk?188"></a>

&gt; The resource share usage is much better in 4.09, but it is still quite
&gt; possible to blow past a deadline (in some cases without ever having started
&gt; the WU).

There is an inherent conflict between deadlines and the timeslicing approach, which is why some of us were saying months ago that preempting wasn't going to be the easy solution some were hoping.

Presumably, keeping the cache small (

&gt; The resource share usage is much better in 4.09, but it is still quite
&gt; possible to blow past a deadline (in some cases without ever having started
&gt; the WU).

There is an inherent conflict between deadlines and the timeslicing approach, which is why some of us were saying months ago that preempting wasn't going to be the easy solution some were hoping.

Presumably, keeping the cache small in preferences helps. And yes, I do understand why SETI fans like big caches. ;)

It's an argument against artificially short deadlines from projects.

&gt;
&gt; &gt; The resource share usage is much better in 4.09, but it is still quite
&gt; &gt; possible to blow past a deadline (in some cases without ever having
&gt; started
&gt; &gt; the WU).
&gt;
&gt; There is an inherent conflict between deadlines and the timeslicing approach,
&gt; which is why some of us were saying months ago that preempting wasn't going to
&gt; be the easy solution some were hoping.
&gt;
&gt; Presumably, keeping the cache small in preferences helps. And yes, I do
&gt; understand why SETI fans like big caches. ;)
&gt;
&gt; It's an argument against artificially short deadlines from projects.
&gt;
Once I understood (had explained) the ramifications of a preemptive scheduler, I was of the opinion that it was going to be rather difficult to design a good one. It would have to give 100% cpu to a WU that was in danger of being late, and then not allow that project to download more work for some time in order to allow other projects to catch up. Note that the CPU scheduler cannot wait until the deadline has passed to give all of the resources to the late WU as that is too late.

I believe that it is possible:
1) Allow debt to be negative.
2) If the estimated time to crunch a WU is ever 80% or more of the time remaining to the deadline, that WU gets 100% of the crunch time until it is less than 80% of the time remaining to the deadline. If a deadline is less than 12 hours away, that WU is to be completed immediately even if the crunch time is less than 80% of the time remaining to deadline.
2a) In the case of conflicts in 2 where there is more than one WU that meets the criteria, the WU with the shortest deadline gets the priority.
3) A project that has a negative debt will not be eligible to DL new work unless no work is available from any project with a higher debt.
4) If during downloading of work, any WU arrives where the estimated crunch time meets condition 2, do not download any more work from anywhere.
5) If a CPU is idle, download a WU from the project with the highest debt that has work available.

I have probably missed a case. Implementing this is not going to be easy.
<a href="http://www.boinc.dk/index.php?page=user_statistics&amp;project=cpdn&amp;userid=13"><img border="0" height="80" src="http://13.cpdn.sig.boinc.dk?188"></a>