There are also in some cases major differences between the DCF required for
different fpops_est values for the same application. In particular, it
would be good to have the DCF converge more rapidly if the fpops_est was
modified to be more reasonable (i.e. the DCF required has several digits
between the first significant digit and the decimal point).
I would like to propose a class that maintains the mean and standard
deviation. We would then have this class be members of current classes for
several different things: DCF, run time after 100% complete, run time
between checkpoints, time between initial upload attempt and upload
complete, and time between initial report attempt and report complete.
The DCF should be kept for the project, the application, and the
application - fpops_est combination, and the tightest fit that has
sufficient data (sufficient data is 2 tasks complete to get the standard
deviation to work) used for CPU scheduling (mean + 3 standard deviations).
The project DCF would have to be used for work fetch (mean only in this
case). There would still be a bonus for getting the DCF nearly the same
for the different applications for work fetch, but the CPU scheduler would
be able to do better.
The run time after 100% complete, run time between checkpoints, time
between initial upload attempt and upload complete would be used to improve
the ability to determine when to enter EDF. At the moment, it is quite
possible to return late work because there is no preemption for tasks that
might return the work late. So, better would be to reduce the computation
deadline for all tasks by the time between checkpoints for the application
with the longest time between checkpoints, and reduce the computation
deadline for a task by the run time after 100% complete for the application
+ upload time for the project + report time for the project.
The above would give better estimates of when EDF was needed without the
seesaw effect that is being seen, and it would reduce the response time for
a new application or fpops_est to 2 tasks from the possibly thousands that
are needed currently. I would like to suggest that at the same time we do
this, we remove the artificial limit of 100 on the DCF for the project.
jm7
TarotApprentice
<tarotapprentice@
yahoo.com> To
Sent by: BOINC dev
<boinc_dev-bounce <[email protected]>
[email protected] cc
u>
Subject
Re: [boinc_dev] DCF per app
03/08/2010 03:00
AM
As you point out Dave said on the ticket "End of August" (2009). We are
well past that now. Perhaps it can get bumped up the priority list. It
might also solve some of the over/under work fetch issues people have been
having. For those that are interested Jord has put a link to it below.
Thanks
MarkJ
________________________________
From: Jorden van der Elst <[email protected]>
To: TarotApprentice <[email protected]>
Cc: [email protected]
Sent: Mon, 8 March, 2010 5:31:42 PM
Subject: Re: [boinc_dev] DCF per app
It wasn't put into the "too hard" basket. It was put into the "end of
August **or so**" basket.
http://boinc.berkeley.edu/trac/ticket/812#comment:3
"Maintaining per-app-version DCF in the client isn't too hard, but
that's only part of the job; DCF is also used by the scheduler to
decide what jobs can be sent. For this, we'd also need to add to
scheduler requests a list of app versions and their DCFs, and extend
the scheduler to parse this and use the DCFs if present. I won't have
time to do this until late Aug. or so. "
On Mon, Mar 8, 2010 at 7:25 AM, TarotApprentice
<[email protected]> wrote:
> I did raise a Trak ticket for this quite some time back but it was put
into the "too hard" basket. I would add that most projects seem to have
multiple apps these days, examples apart from yours are Seti, Einstein,
GPUgrid and ClimatePrediction to name a few more. Perhaps we could take
another look at it again please.
>
> Cheers,
> MarkJ
>
> ________________________________
>
>
> Date: Sun, 7 Mar 2010 18:43:36 +0200
> From: Rytis Slatkevi?ius <[email protected]>
> Subject: [boinc_dev] DCF per app
> To: BOINC Developers Mailing List <[email protected]>
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset=UTF-8
>
> I am going to raise DCF per app question once again.
>
> PrimeGrid currently has 13 different applications with varying task
> durations and optimization levels for different CPUs. Also available are
GPU
> apps. This makes it very hard to correctly estimate the duration of
tasks,
> and it throws BOINC duration estimate very much off when you run more
than
> one application type. For example if you ran an app which was
overestimated
> and had short tasks, and then switched to an app which has long tasks
that
> are overestimated, it would make it seem that they will run for months,
> which leads to user complaints and lost CPU time because of WUs being
> cancelled, sometimes with a few days of progress.
>
> This has become a number one problem being discussed in the PG forums.
> Therefore I'm going to ask to once again reconsider implementing DCF per
app
> instead of having it per project only.
>
> --
> Pagarbiai / Sincerely
> Rytis Slatkevi?ius
>
>
>
> _______________________________________________
> 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.
>
--
-- Jord.
_______________________________________________
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.
