It may take a few tasks from the low resource share project to get it into
the overworked state (an entire days worth of work run), it really depends
on the length of the tasks.  Then you will not hear from it again unless
your high resource share project is out of work.

jm7


                                                                           
             "Lynn W. Taylor"                                              
             <[email protected]>                                             
             Sent by:                                                   To 
             <boinc_dev-bounce         [email protected]          
             [email protected]                                          cc 
             u>                        [email protected]  
                                                                   Subject 
                                       Re: [boinc_dev] Suggestions         
             01/26/2010 01:08                                              
             PM                                                            
                                                                           
                                                                           
                                                                           
                                                                           




As I understand the concept of a "backup project" it is a last resort,
when you can't get anything else, do this.

If you have a 1,000,000:1 ratio between projects, it seems IOTTMCO that
after the first work unit, the project with the lowest share will go for
years before it fetches ever again.

The only difference between a "true" backup project and a really big
resource share is that the backup project will only occasionally get
work, while the one with the high resource share might do one work unit
once in a while if the "main" projects are always healthy.

We keep coming back to "high priority" as if it's a problem.

If the BOINC client downloads work, it is obligated to return it on
time, otherwise your waste clock cycles would be wasted, and the project
would be passing out work with no benefit to the project.

BOINC isn't just for the crunchers.  Projects have a say too.  I don't
know why projects would want machines that don't return work except when
some other project runs dry -- the best that can do is soak up work that
would have gone to their loyal participants.

As for setting cache sizes and WU limits "by project" that sets too many
limits on work fetch to be able to follow resource share.

-- Lynn

Raistmer wrote:
>> Set the resource share of the backup project to be really tiny compared
to
>> the primary project.  A ratio of a million to 1 is possible, and that
>> would
>> have the backup project only doing an hour of work every century on its
>> own, after a few tasks to get it into the overworked state.  Set your
>> "Connect every X" to match reality (0 if you are always connected), and
>> your "Extra work" to be a couple of days (long enough for most
outages)l.
>> An overworked project (and the low resource share project in this case
is
>> almost certainly going to be overworked) will only be asked for work if
>> the
>> total queue is < "Connect every X".
>>
> No, this will no way be the same as true "backup project" feature.
> With big difference in resource shares all downloaded work will
immediately
> go into high priority and such project will always do more work when
> actually needed as it would be only backup project to some other project
> that time to time out of work.
> Backup project feature requested many times indeed and very useful and
> needed feature IMO.
>
> _______________________________________________
> 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