The RAC near the beginning of the test will be way off because of the
startup to get Einstein below the workfetch cutoff. However, the RAC for
Einstein should slowly drop.
I am not exactly certain where the changes were made, but upgrading to the
latest test build would do.
jm7
Raistmer
<[email protected]
> To
Sent by: "Ed A" <[email protected]>,
<boinc_dev-bounce <[email protected]>
[email protected] cc
u> [email protected],
[email protected]
Subject
01/26/2010 02:59 Re: [boinc_dev] Suggestions
PM
Well, OK, I will try EXACTLY that config.
Will report Einstein's RAC/SETI's RAC on that host cause it will be good
indicator for if project shares are obeyed
or not
What BOINC version intended to work correctly with project shares? I use
6.10.16 on that host, to what build I should upgrade if should?
----- Original Message -----
From: <[email protected]>
To: "Ed A" <[email protected]>
Cc: <[email protected]>; <[email protected]>
Sent: Tuesday, January 26, 2010 10:52 PM
Subject: Re: [boinc_dev] Suggestions
> EDF is NOT a problem. Deadlines must be met once the task is on the
> computer. EDF is not going away.
>
> Have you actually tried my suggestion with the current code? The current
> code does work differently than somewhat older code.
>
> s...@h at 1,0000,000, Einstein at 1, "Connect Every X at 0, and Extra work
at
> 2. Then leave it alone for several weeks to see what happens. Einstein
> will start off by doing about a days worth of work to prime the system.
> What happens after that? If it really down loads a huge amount of work
> after the first day from Einstein, then there is a bug someplace.
>
> jm7
>
>
>
> Ed A
> <canoebey...@gmai
> l.com> To
> Sent by: [email protected]
> <boinc_dev-bounce cc
> [email protected]
> u> Subject
> Re: [boinc_dev] Suggestions
>
> 01/26/2010 02:39
> PM
>
>
>
>
>
>
>
> Unfortunately this solution is not a solution. What too often happens is
> that the primary project will run out of work for an instant and the
> "backup
> project" then DLs massive amounts of work that has to be aborted or will
> go
> into panic mode because of the low resource share. The situation is
> completely untenable for projects that allow only limted WU downloads
> (like
> Yoyo ECM, MilkyWay, GPUGRID, etc). Many of us have tried workarounds for
> years and the only solution that ever worked was to use an alternate
BOINC
> clone such as BoincStudio. These options should be simple to add as
> they've
> been implemented by hobbyists before. If you don't want them to be
> generally available to novice users simply put them in an "expert"
section
> or implement them in one of the text files if you must. Even that would
> be
> better than the current situation.
>
> Please don't get me wrong, I feel that BOINC has been a great
> accomplishment. It's getting better and better. Most recently the ATI
> support has been a wonderful addition. There is a lot of grumbling out
> there among the experienced users though and almost all of it has to do
> with
> the inability to manually control the application better.
>
> Regards/Ed
>
>
> 2010/1/26 <[email protected]>
>
>>
>> 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".
>>
>> jm7
>>
>>
> _______________________________________________
> 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.
