On Apr 22, 2009, at 12:24 AM, David Anderson wrote:
> There are many reports that the current client preempts
> jobs before their time slice is up, for no good reason (see below).
>
> The code that enforces time slicing (from client/cpu_sched.cpp)
> is as follows (line 913)
> preempt_atp = preemptable_tasks.back();
> if (rp->project->cpu_pwf.deadlines_missed_copy ||
> finished_time_slice(preempt_atp)) {
> ...
> preempt_atp->next_scheduler_state =
> CPU_SCHED_PREEMPTED;
>
> In other words, it only preempts a job if its time slice is up,
> or if there's a job in deadline trouble.
> finished_time_slice() is define on line 134:
>
> static inline bool finished_time_slice(ACTIVE_TASK* atp) {
> double time_running = gstate.now - atp-
> >run_interval_start_wall_time;
> bool running_beyond_sched_period = time_running >=
> gstate.global_prefs.cpu_scheduling_period();
> double time_since_checkpoint = gstate.now - atp-
> >checkpoint_wall_time;
> bool checkpointed_recently = time_since_checkpoint < 10;
> return (running_beyond_sched_period && checkpointed_recently);
> }
>
> I haven't been able to find the problem here.
> A big (virtual) prize will go to anyone who can.
Just fixing this area (well, line 843 neck of the woods) is not going
to solve the problem.
Scenario, 12 hour TSI, IBERCIVIS downloads 8-10 tasks with 30 minute
run times, deadline 2 days hence ( common occurance with batch
download, most tasks have the same deadline or close to it).
The current code usually slams 4-6 of those tasks into work
immediately on the first loop through. Reason, all currently running
tasks are flagged as next state preempt and the IBERCIVIS tasks are
dying to run so they get scheduled in without regard to TSI as that
part of the code is never executed.
*IF* that is changed, for example, not pre-flagging all tasks as pre-
empted (or deciding only which tasks are pre-emptable before flagging
them as such)... may not cure this.
The client is seeing the IBERCIVIS tasks in deadline trouble BECAUSE
of the long TSI. So, with the change instead of them all getting
slammed in at once, they will now ripple in as BOINC is still going to
consider them in deadline jeopardy.
A more logical test, though more complex is to test the estimated time
to completion (using the ever handy DCF to see how real that estimate
is) to calculate the remaining run time of the tasks on hand. Those
times should be used. Moreover, if all the tasks in jeopardy are from
the same project, we should look to see if a stream of them with the
next to complete task would still allow us to meet the deadline goal.
I mean, dedicating one resource to the processing of a stream of tasks
is acceptable if this type of situation arises ... but to suddenly up-
end the apple cart when we can easily handle the load makes no sense.
Sorry to bring bad news, but better early than later ...
_______________________________________________
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.
