What do we mean by 'use' a certain fraction of a CPU, anyway? AFAIK, projects have a rather crude tool by which they declare what proportion of an application's fpops are performed on the CPU - <cpu_frac>x</cpu_frac> in the xml format of the plan class definition - and nothing else. The *scheduled* CPU usage (and I assume this is what David is referring to) is calculated by the server from this frac and the relative speeds of the host's CPU and GPU.
These limited tools can lead to assumptions which are widely divergent from reality, in either direction. A concrete example: I run two hosts on GPUGrid (who should know a thing or two about GPU programming) Host 43404 is told to schedule 0.55 CPUs for each GPU task: host 132158 is told to schedule 0.667 CPUs. Not a great deal of difference. But compare the reality. http://www.gpugrid.net/results.php?hostid=43404&state=3 uses typically ~900 CPU seconds per task, just 0.06 CPUs http://www.gpugrid.net/results.php?hostid=132158&state=3 uses ~30,000 CPU seconds per task, or over 0.99 CPUs Both hosts are running CUDA 4.2 applications/runtime, but there are many differences between them. GPU type: Fermi/Kepler GPU driver: 310.70/314.22 Operating system: WinXP-32/Win7-64 BOINC version: v6.12.34/v7.0.64 BOINC mode: Service/User Application: Short (v6.52)/Long (v6.18) We could - conceivably - program the BOINC platform to take account of all these variables, but I suspect that would be absurdly complicated, and quite probably fruitless (from reading the project message boards, I suspect the main cause of the difference between 0.06 CPU and 0.99 CPU usage is the current handling of the newer Kepler architecture - so an application-level, rather than BOINC, issue) All-in-all, I think it would be better to go back to using the CPU throttle/thermal control feature for its original purpose - controlling the thermal output of pure-CPU apps (defined as apps which have *no* co-processor specified). If we need a thermal control mechanism for GPUs (which was the original request by Admin Team "St.Petersburg"), add one properly tailored to the hardware characteristics of co-processors. >________________________________ > From: "McLeod, John" <john.mcl...@sap.com> >To: David Anderson <da...@ssl.berkeley.edu>; "boinc_dev@ssl.berkeley.edu" ><boinc_dev@ssl.berkeley.edu> >Sent: Monday, 8 July 2013, 16:21 >Subject: Re: [boinc_dev] CPU throttling and GPU apps > > >How about changing it to not throttle apps that use less than the current >throttling value? E.g. if throttling is set at .9, don't throttle a task that >uses .8. > >-----Original Message----- >From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of David >Anderson >Sent: Friday, July 05, 2013 11:50 PM >To: boinc_dev@ssl.berkeley.edu >Subject: Re: [boinc_dev] CPU throttling and GPU apps > >I changed it not throttle apps that use < .5 CPUs >-- David > >On 04-Jul-2013 2:38 PM, Eric J Korpela wrote: >> The only pro I can think of would be to reduce GPU use to keep >> temperature or power use down, but that would be better implemented as >> GPU throttling. >> >> On Thu, Jul 4, 2013 at 5:52 AM, Bernd Machenschalk >> <bernd.machensch...@aei.mpg.de> wrote: >>> On 04.07.13 13:15, Heinz-Bernd Eggenstein wrote: >>> >>>> I guess there are several pros and cons, e.g.: >>>> >>>> cons: >>>> - one one hand, GPU apps (depending on the CPU share?) get a higher OS >>>> prio (in terms of "niceness") to prevent the GPU being starved. Throttling >>>> the CPU might very well cause this starvation >>>> - if a GPU app has a rather low CPU runtime share in the first place, >>>> further CPU throttling does not seem too useful. >>>> - in order to avoid GPU load to interfere with the user doing non-BOINC >>>> related stuff, there is already the setting "Suspend GPU work while >>>> computer is in use". >>> >>> >>> Here's one more: >>> >>> When not synchronized with GPU-CPU communication (kernel launches, data >>> transfer) throtteling an App can break any running GPU task. I'm not sure >>> whether the throtteling implementations of all BOINC Clients that are being >>> used properly honor critical sections, nor am I that all GPU apps of all >>> projects make proper use of these. >>> >>> >>>> pros: >>>> I can't think about many >>> >>> >>> Actually I can't think about any. >>> >>> Best, >>> Bernd >>> >>> >>> _______________________________________________ >>> boinc_dev mailing list >>> boinc_dev@ssl.berkeley.edu >>> 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 >> boinc_dev@ssl.berkeley.edu >> 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 >boinc_dev@ssl.berkeley.edu >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 >boinc_dev@ssl.berkeley.edu >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 boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.