OK, So my way of thinking should then be adjusted? A one day additional work request is no longer a cache, no longer a work buffer?
This still doesn't explain then why when I ask for CPU work only, I DO NOT get any work, while when I ask for CPU work with a GPU work request piggy-backing itself onto the work request, I DO get work for the CPU. It also doesn't explain why, when I do CPU only work requests, I only have the 4 tasks in cache that are running on the CPU cores. That as soon as one core is about to run dry, that a work request is done to another project, and 4 tasks of that project are gotten, regardless of their run time (12 hours or 43 minutes). It also doesn't explain then why, when I allow CPU work requests with a GPU work request piggy-backing onto the CPU, I do get lots of work from at least 4 projects, enough to fill a one day cache. That as soon as one core is about to run dry, that a further project is asked for work and work is gotten in. That then at all times I have 4 tasks per project in cache, while only 1 task per project is running. All work in cache is only CPU work. I have NO GPU work. I have GPU work requests, but none of the projects I run use ATI GPUs. I'm just trying to understand what I am seeing. On Tue, Aug 2, 2011 at 3:34 PM, <[email protected]> wrote: > 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. > > > > -- -- 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.
