I believe that the problem I was complaining about was completely mis-understood. Therefore I will try restating the problem.
Project A has a resource fraction of 0.0001 (yes, very small). Project B has a resource fraction of 0.9999. Project B has enough work to keep the computer busy for a while. Project A run times are 2 minutes + or - 5 seconds. Estimated at 2 minutes (accurate estimate, it is NOT a DCF issue). Project A has the highest LTD by several thousand seconds as Project B has moderately tight deadlines, and is recovering from over work. Project A downloads 20 tasks at time 0. Based on the resource fraction, these are estimated to take a total of 40,000 minutes to complete in Round Robin. This is in excess of the deadline. Project A starts 2 of these tasks (one per CPU) in EDF. 2 minutes later, one of these two tasks completes. The other has 1 second left on the clock. The task with 1 second left is now pre-empted. 2 new tasks are started. 2 minutes later, one of these tasks is completed and one is left with 1 second left on the clock. The task with 1 second left is now pre-empted. ... This continues for 10 rounds until there are 10 tasks completed, and 10 tasks with a second or two left to complete. Now since there is not enough work for this project, and it is not in EDF, and it still has a LTD that is not below the cutoff, 20 more tasks are downloaded. Repeat above. At the end of the second repeat, there are now 20 tasks with a second or two of computation left. This is a bit maddening at this point. The solution: Unless a task is near deadline trouble in EDF as well as RR, do not preempt a task that has not reached its time allocation and gotten to a checkpoint. Of course, if a task is in deadline trouble in EDF and RR, it gets the CPU immediately. jm7 _______________________________________________ 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.
