No, your suggestion is not correct behavior. It is worse than current
behavior.
Projects A, B, C.
Project A starts in EDF with an STD of -86400.
Project B starts with work with an STD of 86400.
Project C starts with no work and an STD of 0
Project A gets far enough to get out of EDF and a task from Project C is
downloaded. Project C STD is 0.
Project A immediately enters EDF again because of the extra work supplied
for C..
Project A completes during that contiguous run. Just before completion the
STDs are -86400 for A, +86400 for B, and some small positive value for C
(due to truncation, it may not be quite 0).
After Project A is complete, the STD values are: 43200 for A, 0 for B, and
-43200 for C.
Now immediately B gets a work fetch.
Current result:
A = 43200
B = 0
C = -43200
Your proposal:
A = 43200
B = 43200
C = -43200
Shift then occurs...
A = 28800
B = 28800
C = -57600
Both of these heavily penalize project C. It has work on the system, has
not done any work, and has a very negative STD. More negative undere your
proposal.
My proposal: (as similar as can be arranged for starting conditions.
Project A starts in EDF with an STD of 0.
Project starts with work with an STD of 86400 (or whatever we define the
max STD to be).
Project C starts with no work.
Project A gets far enough to get out of EDF. Project C downloads some
work. Project C STD is 0.
Project A immediately enters EDF again because of the extra work supplied
for C.
Project A completes during that contiguous run. Just before completion the
STDs are 0 for A, 1000 for B (assumes some time running A), and 86400 for
C.
After Project A completes, the STDs are 0 for A, 85400 for B, and 0 for C.
Project B now gets work.
Result of my proposal.
Project A has an STD of 0.
Project B has an STD of 85400.
Project C has an STD of 0. (yes there is a slight penalty, but not nearly
as severe as the other two ways of doing it.).
I have watched this scenario play out over and over and over again. It can
be a very long time before Project C ever gets a chance to run - usually in
EDF because its deadline is near.
Of course, these all go away if we deal strictly with long term debt, but
that generates other problems on multi CPU systems. I currently have a
scenario where CPDN has downloaded 7 tasks for my 8 processor machine.
Some of them have completed, and the LTD for CPDN is around -4.5 million.
There is typically one CPDN task of the set of 7 that has not been running
because the CPDN STD has been pegged at -86400, but because of resource
shares, there has only been one or two projects with a high enough STD so
that work would be requested. If this CPDN task would only be run based on
LTD, it will be several weeks before it ever gets a chance to run. If
based on STD, as soon as the rest of the CPDN tasks finish the STD of CPDN
will start to rise, and it will get a chance to run every day.
jm7
David Anderson
<[email protected]
ey.edu> To
Sent by: [email protected]
<boinc_dev-bounce cc
[email protected] [email protected]
u> Subject
Re: [boinc_dev] Short Term Debt.
12/07/2009 01:44
PM
A possible problem with that is:
suppose project A has a long job in EDF,
project B has a runnable job, and project C doesn't have a job.
Then A's STD would be zero,
and B's STD would go to MAX_STD (1 day).
If A's job finishes and C gets a job,
it wouldn't run for a day;
in effect, C would be penalized for A's deadline crisis.
An alternative: add the normalizing offset to non-runnable projects.
In the above case, C's STD would go to MAX_STD,
and it would start off on equal footing with B,
which is the correct behavior.
-- David
[email protected] wrote:
> I believe that the system would work better if the minimum short term
debt
> were 0 rather than the mean short term debt being 0. Typically what
> happens is that the task that has just completed has a negative STD. If
> this is the last one for the project, many of the tasks with higher STDs
> are shifted to have a negative STD. If the project then is allowed to
> download a task immediately (and this does often happen) the project will
> then have a STD of 0, effectively bypassing other projects that used to
> have a higher STD.
>
> If the minimum STD were kept at 0, this would not happen. When the
lowest
> value STD project was removed from the STD, the next lowest value STD
> project would then have a value of 0. This starts all new tasks from
> projects at the bottom, and they may have to wait for a while for their
> turn. However, it does mean that projects that have had work on the
system
> will eventually have the STD be high enough to actually run.
>
> jm7
>
_______________________________________________
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.
