I was thinking more in line of having a "early report bonus deadline" in
addition to the "report deadline" as an optional parameter per task. If
returned by the early report deadline, the project would give the bonus.
This would allow the client to schedule in the following way:
1) EDF if needed to meet the report deadline.
2) EDF if needed to meet a bonus deadline.
3) Round Robin for CPU or FIFO for GPU.
Either that or a flag set by the project that results need priority. In
this case, the host would run tasks:
1) EDF if needed to meet the report deadline.
2) FIFO from the project with the nearest deadline that needs results back
high priority.
3) Round Robin for CPU or FIFO GPU.
Of course, the project would very likely NOT be getting a fresh download as
it would become quickly overworked.
jm7
Martin
<[email protected]
o.uk> To
Sent by: BOINC Developers List
<boinc_dev-bounce <[email protected]>
[email protected] cc
u>
Subject
Re: [boinc_dev] [boinc_alpha] Card
09/28/2009 04:40 Gflops in BOINC 6.10
PM
[email protected] wrote:
> Any bonuses for something like turn around time should have support built
> into the client so that multi project users are not penalized. You are
> indeed talking about penalizing multi project users by not allowing them
to
> earn the bonus points for turn around time.
There's an old saying about not being able to have your cake AND to
(also) eat it.
Multi-project users should be able to earn their fast turn-around time
bonuses if their systems are fast enough and the Boinc scheduler gives
the bonus jobs priority. To my mind, that is far far more 'honest' and
less wasteful with abandoned WUs than inducing EDF with a fictitiously
short deadline.
This is another very good reason for the scheduler to schedule the tasks
according to the _credits_ gained in proportion to the set user resource
shares.
Hence, if the resource share was scheduled according to the credits
awarded:
1: Any 'bonuses' awarded by a project (for example for a fast
turn-around time) will have a mitigating 'cost' to that project of
reduced CPU time in proportion to other projects on a host;
2: There will be natural "market forces" pressure upon the projects to
award credit fairly to maintain a fair share of CPU time for their project;
3: Users will at last see the scheduler *successfully* balance the
resource shares to give credits in proportion to the user set resource
shares.
Point "3" is especially important to avoid the forum questions about
resource shares not being visibly "honoured" in the awarded credits.
Regards,
Martin
--
--------------------
Martin Lomas
m_boincdev ml1 co uk.ddSPAM.dd
--------------------
_______________________________________________
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.
