John, I know that you're a veteran BOINC user and very knowledgeable, but are you running a variety of GPU projects, especially on machines with multiple GPUs? Work fetch with CPU projects is not as large a problem unless you're trying to use an app_config.
Regards/Ed On Wed, Feb 27, 2013 at 8:06 AM, McLeod, John <[email protected]> wrote: > I believe you have missed part of the point of the work fetch algorithm. > It uses work fetch to balance out the work done over the long term to > match your resource shares. There is no guarantee that the client will be > running exactly N of project A and M of project B. In general, set the > resource shares the way you want to share the work load, and don't try to > micro manage it. Just let it balance things out over the long term. > > It is possible to sign up for more projects than you have processors, and > sometimes projects are down or are out of work. Some projects have very > tight deadlines, and need every processor when work is downloaded. > > -----Original Message----- > From: [email protected] [mailto: > [email protected]] On Behalf Of Ed A > Sent: Tuesday, February 26, 2013 3:38 PM > To: Rom Walton > Cc: BOINC Developers Mailing List; BOINC Alpha Mailing List; Steffen Möller > Subject: Re: [boinc_alpha] [boinc_dev] Boinc alpha and the testing future > (patchincluded) > > The biggest problem I deal with is work fetch. I'm running into regular WU > starvation. GPU work fetch with exclusions and 2 same type GPUs is still > not fixed. In addition when using an app_config to limit instances of any > given CPU app I often find the other CPU app unable to get work with the > dreaded "not needed" or "project not the highest priority" messages. The > only way to get new work is to suspend work fetch on every project but the > one starved and then manually poll for it. A major ongoing frustration, > but otherwise the CPU cores sit idle. Can't there AT LEAST be a mechanism > where when we manually poll for work the client allows it? > > Thanks/Ed > > > > > On Tue, Feb 26, 2013 at 2:21 PM, Rom Walton <[email protected]> wrote: > > > Well since we haven't begun work on a 7.2 release, everything committed > > since 7.0.28 is technically a bug fix. > > > > Even the app_config.xml configuration file ( > > http://boinc.berkeley.edu/trac/wiki/ClientAppConfig) started its life as > > a power user bug fix. Ideally, at some point in time, we can figure out > a > > sane set of policies that the client/server can use to implement that > > functionality automatically. > > > > I recognize Steffen, Gianfranco, and all the Linux package maintainers > > have a really hard job. They are constantly trying to balance BOINC > > project goals with the Linux distro policies. > > > > From my perspective any build in the 7.0b branch past 7.0.28 should be > > able to be considered stable from a package maintainers perspective. Do > I > > need to change something to better support our Linux package maintainers? > > > > ----- Rom > > > > -----Original Message----- > > From: [email protected] [mailto: > > [email protected]] On Behalf Of Toralf Förster > > Sent: Tuesday, February 26, 2013 12:36 PM > > To: [email protected] > > Subject: Re: [boinc_alpha] Boinc alpha and the testing future > > (patchincluded) > > > > Probably Steffen compares the current BOINC version history + release > > management with the one of the linux kernel development model (which I > like > > too). > > > > Said that, he's expecting (and I'd appreciate that too) that 7.0.x is > just > > a bug fix version of 7.0.(x-1) rather than a feature-added version, > right ? > > > > -- > > MfG/Sincerely > > Toralf Förster > > pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 > > _______________________________________________ > > 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. > > _______________________________________________ > > 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_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. > _______________________________________________ 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.
