The new work fetch policy is to wait until the work buffer is at or below
the connect interval before requesting work. In your case, that number is
0 seconds. It also does not work very well for that as there is time for
the request and download that has to be taken into account.
A minor modification to the algorithm for determining when to trigger a
work fetch might be in order. I would propose that the trigger point be
changed to max(connect interval, connect interval + extra work / 2); This
should work OK both for people that have an always on connection and for
those that have an intermittent connection.
jm7
Jorden van der
Elst
<[email protected] To
> <[email protected]>
cc
08/02/2011 09:17
AM Subject
Re: [boinc_alpha] BOINC 6.13.1
released for all platforms
Perhaps that you can then explain this one, John.
Doing it off list for now. David has so far not explained it to me. I
have the connect to of 0.00 days and additional work request of 1 day.
02/08/2011 06:59:50 | | [rr_sim] start: work_buf min 1 additional
86400 total 86401 on_frac 0.960 active_frac 0.514
When I run BOINC with the ATI GPU detection disabled or ignored, so
that there's only CPU work asked, I eventually run only with 4 tasks
constantly.
BOINC will fill up when it fears a CPU core will get dry. It doesn't
matter if that's with projects that run 12 hour tasks (per core) or 43
minutes. It will not ask for my 1 day additional work.
It will not ask other projects for work, and if I do a manual force,
all the work requests are for 0.00 seconds. Again, it will only ask
work when a CPU is about to fall dry.
All of these projects do CPU work only.
However, next I enable the ATI GPU and restart BOINC. I ask work from
all the same projects as before and now it will go by them all and ask
for 1 second of work, or 23,000 seconds, or 54,000 seconds.
It gets work from multiple projects. Multiple tasks (mainly 4) per
project. All only CPU work. When any of the projects with work in
cache have finished a task, any next project is asked for work to fill
up the cache.
I have now always work from at least 4 projects in cache, mainly 4
tasks per project.
So... is that a bug then?
I see it as a bug. I have sent logs to David, side by side even, of
work requests only done on CPU, and for CPU when the ATI GPU is
detected and enabled to ask for work (but not getting any).
He apparently doesn't see it.
What do you see? Difficulty in me explaining? ;-)
On Tue, Aug 2, 2011 at 3:06 PM, <[email protected]> wrote:
> Disconnected duration seems a better description, but it may be too
> "techy".
>
> The new work fetch policy means that there should be more pressure to get
> the Recent Work Done half life right. Long running tasks will tend to
run
> solo for much of their duration. Yes, this will drive up the recent
> average work done for that project, but, if the halflife is too short,
not
> as much as it should, and it will fall much too fast.
>
> jm7
>
>
>
> David Anderson
> <[email protected]
> ey.edu> To
> Sent by: Jorden van der Elst
> <boinc_alpha-boun <[email protected]>, BOINC Alpha
> [email protected]. list <[email protected]>
> edu> cc
>
> Subject
> 07/31/2011 12:50 Re: [boinc_alpha] BOINC 6.13.1
> PM released for all platforms
>
>
>
>
>
>
>
>
>
>
>
>
> On 31-Jul-2011 7:46 AM, Jorden van der Elst wrote:
>
>> I set up BOINC to have a connect to of 0.00 days, plus additional work
>> of 1 day. I would expect BOINC to then have at least 1 day worth of
>> work in cache at any time.
>
> The new work fetch policy is:
> - wait until work supply falls below lower limit ("connect period")
> - fetch enough work to reach upper limit (connect period + additional)
>
> The idea is to make one big request instead of a lot of little requests.
>
> The terminology (e.g., "connect period") needs to be improved.
> Suggestions?
>
> -- David
> _______________________________________________
> boinc_alpha mailing list
> [email protected]
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_alpha
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
>
>
>
>
--
-- Jord.
_______________________________________________
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.
