OK, 5 projects with equal resource shares leads to resource fraction of
0.2. (Which is the same as 20%). This resource fraction might actually be
higher at some times depending on how much work is on the machine from
other projects. For example if there was only work from 4 of the five (and
the fifth was not "the next to get a work request") the resource fraction
would be 0.25. If other projects would run out in the middle, the resource
fraction might be 0.20 at the beginning, 025 a few hours later, 0.33 after
a day, and 0.5 at the end of the simulation. So, the resource fraction
does depend on the other work on the system. The rr_sim also takes into
account the timestats, so the 40 hours will be increased somewhat, but
without knowing all of the numbers from a single snapshot, it is impossible
to determine exactly why the project was in EDF. For example, the CPU
efficiency might have been 0.2 at that point and effectively multiplied all
of the runtimes by a factor of 5. The duration correction factor could
have been higher than reality, increasing the estimated wall times.
Without all of the information needed in a single snapshot, there is just
no way of telling why a task was run in EDF.
jm7
Mikus Grinbergs
<[email protected]>
Sent by: To
boinc_dev-bounces BOINC dev
@ssl.berkeley.edu <[email protected]>
cc
04/30/2009 12:26 Subject
AM Re: [boinc_dev] 6.6.20 and work
scheduling
> 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.
I do not at all understand bringing in "how much OTHER work was
there". If you go back and re-read my original post, you will see
that I said:
>> So why does "scheduling" think there is a potential missed deadline?
>> The only answer I can come up with is that "resource share" is being
>> factored in - if this is one of five projects, then 20% (they all
>> have equal shares) of 70 hours is 14 hours - not enough to do the
>> estimated 40 hours of work. But this is a four-core system -- so
>> 20% of (70 * 4) is 56 hours of crunching that this project is
>> "entitled" to in the next three days.
My understanding of the "resource fraction" is that it is dependent
only on the relative "Resource Share" values for the various
projects attached by that system, and __not__ on "how much other
work was there". [If "resource fraction" is affected by an attached
project being unable to provide work, that would not *decrease* the
"resource fraction" given this project (which did send work).]
Please excuse me that I did not describe everything plainly in my
original post. That system actually *is* attached to five projects
- for each the "Resource Share" value of 100 has been specified
(they are all equal) - so the number of other projects makes the
"resource fraction" of the project that went into EDF no less than
20% (not 0.125 as you speculate).
I fail to see how "how much other work was there" has any bearing on
the decision to run this project in EDF. As I said in my original
post [derived from a calculation similar to yours - my calculation
multiplied the available time by the "resource fraction", whereas
your calculation divided the needed crunching time by the "resource
fraction" - both methods of calculation arrive at the same ratio of
(needed_crunching_calculation) versus (available_calculation)]:
>> A need to do 40 hours of work in three days will potentially miss
>> the target if there are actually less than 56 hours available to
>> this project in that time span. But if they are not available to
>> *this* project, it must be because there is an even greater need by
>> another project. Yet none of the other projects are running in EDF.
To repeat,
>> 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.
