I've found that the Tthrottle program is good for preventing CPU workunits from overheating my laptop, but not so good for GPU workunits - it always slows down the CPU workunits in preference to slowing down the GPU workunits, regardless of the settings. This has, for example, allowed me to run PrimeGrid LLR CPU workunits there without overheating, but they only run at a reasonable speed if I turn off BOINC's use of the GPU.
For some BOINC projects, such as WCG, I'm interested in trying any new apps as they come along. Therefore, I'd like such an option, but enabled only if the user decides to do so. A variation to consider - allow the user to specify that workunits for certain apps shouldn't be sent at all, but the rest of the apps are divided into a group the user prefers and a group for which workunits should be sent only if no workunits for the preferred group are available. New apps should be allowed to default to any of these groups, as the user prefers. I've generally seen "subprojects" used to mean groups of apps that are actually from outside projects - the way it's used on WCG. Robert Miles > Date: Thu, 3 Nov 2011 11:55:07 -0500 > From: Jon Sonntag<[email protected]> > Subject: Re: [boinc_dev] app selection problem > > If I choose to run only certain apps for a project and I choose not to > accept work from other apps when those apps cannot get work, I would be very > unhappy if the project ignored my preferences and decided I should run some > new app without my approval. I chose those preferences for a reason. If I > choose to run only 1 out of 5 apps on a project, I certainly don't want to > get app #6 automatically added when it is released. If I want it, I'll add > it to my preferences. If the project announces the new app and sends a > reminder (isn't that what the new notices are for?) to users to check their > preferences, that is all that is needed. It shouldn't be forced upon > anyone, especially those who chose specifically not to run all apps and not > to select work from any other apps when their selected apps are out of work. > > Here's a real life example: PrimeGrid's LLR apps run very hot and, as such, > are sensitive to overclocking. In the past, they have caused a couple of my > "low profile case" machines that have very poor airflow to overheat. I > still want to contribute to PG, so I avoid all the LLR apps by deselecting > them in my project preferences. If your suggestion were implemented, then if > a new LLR app is released by PrimeGrid, I would get it added even though it > would crash my machines. That's certainly not something for which I'd vote. > I'd want PrimeGrid to honor my preferences and only send the apps I have > chosen. Period. That includes new apps. > > Jon Sonntag > >> -----Original Message----- >> From: [email protected] [mailto:boinc_dev- >> [email protected]] On Behalf Of Bernd Machenschalk >> Sent: Thursday, November 03, 2011 10:32 AM >> To: Peter Slacik >> Cc: BOINC Developers Mailing List >> Subject: Re: [boinc_dev] app selection problem >> >> On 03.11.11 16:15, Peter Slacik wrote: >>> OK, my apology, you've got me. The majority of the projects actually > tell >> something different from what I wrote, e.g.: >>> PrimeGrid project prefs >> (http://www.primegrid.com/prefs.php?subset=project&cols=0 >> <http://www.primegrid.com/prefs.php?subset=project&cols=0>): >>> "/Send work from any subproject if selected projects have no work/". >>> >> "Subprojects" - OK, I now understand why occasionally people in our forums >> confuse apps and projects. Unfortunate wording IMHO. >> >>> Collatz Conjecture prefs >> (http://boinc.thesonntags.com/collatz/prefs.php?subset=project): "/If no >> work for selected applications is available, >>> accept work from other applications?/" >>> >> Both examples would behave differently from my original idea, and I'm not >> even sure this solves the original problem. >> >> These _could_ mean that work is accepted for applications people > explicitly >> opted-out from (at the time of editing preferences), it doesn't say > anything >> about future apps. And these refer only to the situation when there is no >> work available for the selected applications. >> >> If there really was a setting "Automatically send work for future > applications >> not yet mentioned here" I would probably like it (if the default is > "yes"). Any >> hints on implementing it to become a BOINC standard? >> >>> I remember that at least the World Community Grid >>> (https://secure.worldcommunitygrid.org/ms/viewMyProjects.do) suports >>> the application opt-in, in addition to the previously mentioned task >>> opt-in: "/Please opt me in to new projects as they become available/", >>> but I suspect the preferences code has less in common with BOINC trunk >>> :-( >> Literally nothing, that's their own custom code. >> >>>> I still find it overly complicated for both the participant and the >>>> BOINC server to have yet another setting to cover this case which I > don't >> think is a special one, but if other projects got people used to that, I'd > give in >> and adopt it. >>> Personally I'm glad to have such explicit options. When I'm connecting >>> a recent "powerful" (and always-on) machine, and an old "weaky" (or >>> mostly >>> switched-off) machine, to the same project, I may allow the project to >>> send just any tasks to the former one, but have to carefully choose >> applications (according to their crunch time and deadline) to be sent to > the >> latter one - surely with no automatic opt-in. >> >> Doesn't sound like the average participant, though. >> >> Best, >> Bernd >> >> _______________________________________________ >> 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.
