OK, you had a 4 core system. How much OTHER work was there. If the amount
of other work on the system makes the resource fraction for that project
0.125, then the rr_simulator comes up with an answer of 80 hours till
completion again. If the the resource fraction for that project was
0.0625, rr_sim comes up with an answer of 160 hours. The amount of other
work on the system is a crucial input into the rr_sim calculations. The
tasks for one project are not taken in isolation. I keep hearing "The host
downloaded X hours of work with a deadline of Y. Why is it in EDF?". Why
depends on the rest of the system state.
jm7
Mikus Grinbergs
<[email protected]>
Sent by: To
boinc_dev-bounces BOINC dev
@ssl.berkeley.edu <[email protected]>
cc
04/29/2009 11:30 Subject
AM Re: [boinc_dev] 6.6.20 and work
scheduling
> 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.
_______________________________________________
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.
