I checked in the following, which I hope will fix both
the GPU scheduling problem reported by Evangelos,
and the CPU problem reported by John McLeod.
-- David
- client: try to fix situations where the scheduler
runs GPU jobs in a seemingly random order,
or preempts GPU jobs needlessly.
The change has two parts:
1) sort the "results" vector by received_time,
so that the RR simulation processes GPU jobs FIFO
(in case of tie, use something deterministic: result name)
2) in the CPU scheduler (earliest_deadline_result())
instead of choosing the earliest-deadline GPU job that
misses its deadline,
pick the earliest_deadline GPU from a project that
has a deadline miss for that GPU type
(this is what's done in the CPU case)
[email protected] wrote:
> The computer in question has 2 CPUs, and no GPUs.
>
> The problem is that I have 2 CPDN tasks, and after a restart, it insists on
> starting the task that was downloaded more recently if only one CPDN task
> is started. The received_time for both was 0, but even after I changed the
> received_time for the newer one to be greater than 0, the newer one was
> still favored for start over the older one.
>
> Another, but similar problem is that all results that are dowloaded in one
> one batch get the same timestamp. I have 3 tasks from Virtual Prarie on
> that machine with identical non-zero timestamps. It might have been better
> if we used a counter rather than a timestamp for this case.
>
> jm7
>
> _______________________________________________
> boinc_alpha mailing list
> [email protected]
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_alpha
> 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.
