The trouble with this global starting point is that - if selected - it knocks out the subtle, planned, evolved behaviour which BOINC already has for managing priority.
We currently have special priority cases (in the sense of OS run priority - point taken, and well made) for NCI apps, GPU apps, and wrapper apps. All of those go out of the window if the user chooses a Default Process Priority. This feels like a special case for the benefit of users who run one project only under BOINC, and as such rather mitigates against the vision of BOINC as a project-neutral (and multi-project) infrastructure. > On Tuesday, 29 September 2015, 21:00, David Anderson <[email protected]> > wrote: > > We could increase the resolution; > a global setting is a good starting point. > > Just so everyone knows: > this involves the OS priority at which tasks run, > not BOINC's prioritization of tasks (i.e. which ones run first). > > -- David > > On 9/29/2015 1:10 AM, Richard Haselgrove wrote: >> Is it really appropriate for the new Default process priority switch to > operate at the cc_config level? >> >> I'd have thought it was a more natural fit for app_config, so that the > user could adjust the relative priority of different projects, different > applications, and even different app_versions. >> _______________________________________________ >> 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.
