OK, those who have 24/7 connections are supposed to set "Connect Every X"
to zero, so they'd get very minimal work for the backup project while
those who have a larger setting would get at least enough to satisfy that.
Makes sense if users actually follow the recommendations. OTOH, the default
for "Connect Every X" is 0.1 days and maybe should be reduced.
I found in GLOBAL_PREFS::parse_override() in lib/prefs.cpp:
// the following is for compatibility with old schedulers,
// whose work req is just #secs, rather than #sec and #devices
// If this were zero we'd never get work from them
//
if (work_buf_min_days < 0.00001) work_buf_min_days = 0.00001;
That 0.864 seconds is definitely applied to a local global_prefs_override.xml
but I cannot find it or any equivalent applied to global prefs set on the web.
I've probably missed it, or maybe no project is using such an old scheduler.
But I mention it just in case it might cause a backup project work request to
be null.
Just an adjustment to use work_buf_min_days*86400 rather than 1 second for
backup project work requests would fill to that "Connect Every X" level.
Aside from that feature, I still prefer David's hysteresis approach to your
attempt to make BOINC guess what the user needs. Artificial intelligence is
a very interesting field, but so often fails miserably it is best applied
only when it is really needed.
--
Joe
On 9 Aug 2010 at 8:20, [email protected] wrote:
> If it only fetches one task at a time, you will have to decide whether to
> allow BOINC to connect right now or not, when every single task is
> complete. There will be no buffer if you do not allow BOINC to connect,
> you will have idle CPU time. I believe that this will be more annoying
> than using the backup project to fill just to Connece Every X.
>
> My proposal was to have backup fill just to "Connect Every X" and not
> attempt to fill to Connect Every X + Extra work. David's proposal would
> allow the queue to empty too quickly for clients that are not connected.
> As has been pointed out numerous times, setting a very low resource share
> is not the same. Occasionally the very low resource share will fill the
> buffer to Connect Every X + Extra Work.
>
> Yes, the software settings that disallow network connection should count
> the same as having no physical connection at the local machine.
>
> jm7
>
>
>
> "Josef W. Segur"
> <jse...@westelcom
> .com> To
> Sent by: [email protected]
> <boinc_dev-bounce cc
> [email protected]
> u> Subject
> Re: [boinc_dev] Backup Projects
> Work Fetch
> 08/06/2010 10:07
> PM
>
>
>
>
>
>
>
>
> 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.
