I checked in the following change,
which may solve the problem described below.
-- David
- client: change the way a resource's "estimated delay"
(passed to server for crude deadline check) is computed.
Old: estimated delay is the interval for which the resource
is fully used (i.e., all instances busy).
Problem: this may cause unnecessary project starvation.
example: 1 CPU machine, has a month-long CPDN job
with a 1-year deadline (it's not in deadline trouble).
Then the CPU estimated delay will be 1 month,
and the client won't get any work from projects
with deadlines shorter than 1 month.
New: estimated delay is the latest time at which the
resource is fully used and is being used by at least 1 job
that is projected to miss its deadline under RR.
Note: this isn't precise, but I don't think we can improve it
much without getting a lot more complex.
Ian Hay wrote:
> Jonathan Stephenson wrote on 16/07/2009 16:36:
>> I've noticed something strange with the 36 and 37 version as far as work
>> request. When I upgraded to either version, some projects like
>> DrugDiscovery
>> stated that the WUs would not complete in time (BOINC on 99... and
>> active 97
>> or something like that). In particular DrugDiscovery has a resource share
>> ten times any other right now. When I downgraded to 31 DrugDiscovery
>> instantly downloaded 43 WUs.
>>
>> Since the "To completion" for the DrugDiscovery WUs is 1:46 minutes I
>> doubt
>> the error is in the 31 version.
>
> I've looked into at the changes between 6.6.31 and 6.6.37 and it looks
> like the removal of the line
>
> estimated_delay = 0;
>
> from RSC_WORK_FETCH::clear_request() in changeset 18296 is responsible.
>
> I've just self-compiled 6.6.37 after adding the line back in and I'm now
> downloading work from work-starved projects.
>
> Before applying the patch a scheduler request from malariacontrol.net had
>
> <work_req_seconds>17280.000000</work_req_seconds>
> <cpu_req_secs>17280.000000</cpu_req_secs>
> <cpu_req_instances>0</cpu_req_instances>
> <estimated_delay>2441795.222059</estimated_delay>
>
> After the patch it had
>
> <work_req_seconds>17280.000000</work_req_seconds>
> <cpu_req_secs>17280.000000</cpu_req_secs>
> <cpu_req_instances>0</cpu_req_instances>
> <estimated_delay>0.000000</estimated_delay>
>
> The attached file has the rr_sim and work_fetch_debug messages relating
> to these requests.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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.
