> Because scheduling ALSO takes into account the resource share, and a bit of > a safety margin. > > 100 -26.4 - 1 is 72.6 hours. // the -1 is the task scheduling period. If > this is larger, the tasks have to complete earlier. The reason is that the > task scheduling period is the granularity that the CPU scheduler can be > guaranteed to be no larger than. > > 72.6 * 0.9 is 65.34. // just in case they run a little long > > 10 tasks * 4 hours each is 40 hours. > > Assuming that the resource fraction with other tasks on the system is 0.25 > (three other projects with equal share and enough tasks to keep the queue > busy for the 66 hours to deadline - you did NOT specify the other work, so > I have to make this part up), rr_sim will conclude that the tasks will > complete in 160 hours, well PAST the computation deadline in 66.24 hours. > Calculation is for a single CPU. For a dual CPU, rr_sim should calculate > the last task will complete in 80 hours - again past the computation > deadline. > > This is why it currently finds the deadline problems.
I explicitly said this was observed on a *four-core* machine. So if rr_sim thinks a dual CPU would need 80 hours, then it ought to think a four-core machine would need 40 hours -- well within the 65.34 hour available time span you calculated. >> For me, this case does not add up to a "potential missed deadline". mikus _______________________________________________ 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.
