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.
> _______________________________________________
> 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.

Reply via email to