Donating work effectively means meeting deadlines. Sometimes what the
crunchers want is mutually contradictory. This is one of those cases.
Once the work is on your system, it has to be completed by the deadline or
it is worthless.
Try setting extra work to a couple of days so that when SETI has a full
queue, Einstein will not get any in a hurry. SETI should work its way
through the extra work before Einstein is asked for any work at all. This
assumes that you let Einstein prime the system by doing some work up front.
At a ratio of 1000 to 1, you should expect that Einstein will run for 1 day
every 3 years unless SETI is out of work.
Let us examine what the queue is for. "Connect every X" is designed for
users that do not have always on connections so that they can keep
crunching while their machines are disconnected from the internet. "Extra
work" is to have a little work around just in case. Over worked projects
(i.e. projects that have used more than their allotted CPU time by some
amount) do not participate in the "Extra Work" portion of the queue. At
least this is true in the latest builds.
jm7
Raistmer
<[email protected]
> To
Sent by: "Lynn W. Taylor" <[email protected]>,
<boinc_dev-bounce <[email protected]>
[email protected] cc
u> [email protected]
Subject
Re: [boinc_dev] Suggestions
01/26/2010 01:43
PM
All I know that every time SETI have no work and I activate Einstein with
resource share 1:1000 regarding SETI it download FEW, not one (!) tasks and
immediately starts to crunch them.
If SETI have work it will not go back and return CPU for SETI, it will
crunch all those tasks to completion.
And then SETI can have no work again and again few Einstein tasks will
downloaded and crunched to completion and so on and so on.
True backup project would return CPU to main project and get it back ONLY
if
their tasks are REALLY near deadline.
Crunching time for einstein task 6 hours. Deadline - 2 weeks. Then what the
hell it crunches all 6 hours tasks one by one just to download next ones
while it could keep these ones quite until next SETI outage?!
Do you wanna say that 1:1000 just not enough? Or what ?
And, BTW, BOINC _is_ for crunchers. They donate resources and have right to
donate it
1) EFFECTIVELY.
2) Accordingly to their preferences.
My current preferences:
give einstein go only if SETI can't do work. Project shares CAN'T fullfil
this goal.
----- Original Message -----
From: "Lynn W. Taylor" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, January 26, 2010 9:08 PM
Subject: Re: [boinc_dev] Suggestions
> 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.
_______________________________________________
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.
