There's already a queue-filling pseudo-backup project option simply
by setting a tiny non-zero resource share for a project. Coercing
the true backup project option into the same thing doesn't make sense.
With my dial-up connection, I absolutely don't want BOINC deciding
when to jump in and use my bandwidth. Much of the day my hosts do
have active internet connections, but BOINC on each has network
activity disabled. So long as that status is considered the same as
physically disconnected, David's proposal looks quite sane to me with
the minor exception that as stated it may fetch more work than
"network conn interval" + "additional work".
--
Joe
On 6 Aug 2010 at 13:09, [email protected] wrote:
> That doesn't fill the queue enough for a disconnect if the only project is
> a backup project.
>
> Counter proposal:
>
> Everything is in seconds.
> Y = Extra Work.
>
> 1) Use the mean and standard deviation of disconnected times. (X = mean
> (all disconnected intervals) + 3 * stddev (all disconnected intervals))
> 2) For non-overworked projects, start download at X + Y + max(X, Y,
> 86400). Refill to X + Y.
> 3) For overworked and backup projects, start download at X, and refill to
> X. No hysterisis, but we are trying to avoid running out of work before
> the reconnect if the user disconnects from the internet at the end of the
> download. Hopefully this will be fairly rare.
>
> Note: all disconnected intervals could be limited to those of the last N
> months, or possibly the last N disconnects.
>
> If we do this, then we should use the discovered disconnected interval for
> CPU scheduling as well instead of the user specified value.
>
> Option: Add the user specified value for disconnected interval as a single
> data point in the mean and standard deviation. This could be limited until
> the count of data points exceeds some small number (say 10).
> Option 2: If the user changes the user specified value for disconnected
> interval, then drop all other data and start over on accumulating mean and
> standard deviation. The user at that point is indicating that something
> has changed.
>
> jm7
>
>
>
> David Anderson
> <[email protected]
> ey.edu> To
> [email protected]
> 08/06/2010 12:45 cc
> PM [email protected]
> Subject
> Re: [boinc_dev] Backup Projects
> Work Fetch
>
>
>
>
>
>
>
>
>
>
> Speaking of which:
> it seems to me that the current work fetch policy is seriously flawed.
> There are two buffer sizes:
> X = "network conn interval"
> Y = "network conn interval" + "additional work"
>
> The current policy is:
>
> - if queue < Y, get work from a non-overworked project
> - if queue < X, get work from any project
>
> There is no hysteresis. As soon as queue < Y, the client
> will get just enough work (1 or 2 jobs) to make queue >= Y.
> The rate of scheduler RPCs is much higher than it needs to be.
>
> -------------
>
> Proposal:
>
> - keep track of periods during which computation is allowed
> but there is no physical network connection.
> Let X be the longest such period during the past week (or so).
> If X < 1 day, X = 1 day (or so).
> - If queue < X, fetch enough work from non-overworked projects
> so that queue >= 2X
> - If queue < X/2, fetch work from overworked projects as well
>
> COmments?
>
> On 06-Aug-2010 5:45 AM, [email protected] wrote:
> > Except for devices that are offline most of the time this would be true.
> I
> > believe that BOINC should fill from backup projects only till
> > work_buf_min_queue is satisfied ("Connect Every X") as this is what the
> > user has specified as how long the computer may go between connections.
> > The backup project should NOT fill any of the "extra days" other than
> > because tasks are discrete and will slightly overfill the
> > work_buf_min_queue.
> >
> > jm7
> >
> >
> >
> > David Anderson
> > <[email protected]
> > ey.edu>
> To
> > Sent by: [email protected]
> > <boinc_dev-bounce
> cc
> > [email protected]
> > u>
> Subject
> > Re: [boinc_dev] Backup Projects
> > Work Fetch
> > 08/05/2010 04:40
> > PM
> >
> >
> >
> >
> >
> >
> >
> >
> > I think the right thing to do is to fetch only
> > enough jobs to fill up the idle devices,
> > i.e. don't queue extra jobs for backup projects.
> > I'll check this in.
> >
> > -- David
> >
> > On 05-Aug-2010 12:57 PM, Jamie Tiller wrote:
> >>
> >> Hi,
> >>
> >> I may have missed this so forgive me if this has been asked and
> answered.
> >>
> >> I've been having a play with the "Backup Projects" options and think
> that
> > an
> >> extra option should be included in Boinc to utilise this functionality a
> >> little better. Currently, if I'm correct, if no work is available, or
> the
> >> sites are down for any attached projects that have>=1% resource share
> > then
> >> Boinc will look to the projects that have been set to "Backup
> > Projects" (0%
> >> resource share), and request work from those projects. In itself, this
> is
> > a
> >> good way of keeping the computers resources busy. The problem, I think
> > comes
> >> from the fact that the "Backup Project" logic is only tied into which
> > project
> >> to request work from, and not how much work to request. With no manual
> >> intervention for the user, this could lead to the cache being filled
> with
> >> "Backup Project" work. However, if the users main projects start
> > generating
> >> work again, or come back online, this could stop those main projects
> from
> >> requesting work due to having a full cache of "Backup Projects"
> > workunits.
> >> One solution would be to default the work fetch request to only ask for
> a
> >> limited amount of work from the "Backup Projects" at a time, but this
> > could
> >> then lead to issues with users that have limited internet access or
> those
> >> that have "Set& Forget" systems. So, would it be possible to
> incorporate
> >> into the Boinc client an extra option that allows the users to set how
> > much
> >> work to request at a time from the "Backup Projects"? For example, my
> > system
> >> is set to "Always Connected" in the internet options, therefore with
> this
> >> option available, I would be able to set the work fetch requests from
> the
> >> "Backup Projects" for 1 second of work per idle resource which is the
> > same as
> >> when you first attach to a project This would eliminate the need for any
> >> micro-management of the projects when work is unavailable, but still let
> > the
> >> users main choice of projects receive work, and continue to be the main
> >> projects as soon as work is available from them again.
> >>
> >> Thanks Ghost
_______________________________________________
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.
