We implemented a variant of 1), which seems to work fine.
It will be in the 7.4 client, which should be released next month
(we could accelerate this if needed).
-- David
On 06-Nov-2013 8:08 AM, Matthew Blumberg wrote:
Did anything come of the below?
On Feb 28, 2013, at 12:53 PM, David Anderson <[email protected]> wrote:
Originally the app part of the runtime system polled for messages every 1 sec.
At some point (several years ago) I changed this to 0.1 sec.
Throttling uses 1-sec resolution to be compatible w/ old apps.
Note: "1-sec resolution" means the shorter of the 2 intervals
(on and off) is 1 sec.
E.g. 25% throttle is 1 sec on, 3 sec off.
Also: the throttling mechanism turns all jobs on/off, as a unit.
So 2 changes are possible:
1) change the resolution to 0.1 sec if all apps have recent API libs.
2) "stagger" the throttling of jobs
... or a combination of the 2.
1) has the disadvantage that stopping/starting some jobs
(e.g. multi-process) can have large-ish overhead
On 28-Feb-2013 9:29 AM, Kevin Reed wrote:
David,
I have a question about the throttle. At one point Peter Hanappe had worked on
this draft paper which I understand he already shared with you:
/(See attached file: hanappe-slow-computing.pdf)/
In it he describes the power saving benefits of changing the throttling
mechanism to 'fine grained throttling'.
Additionally, we are periodically in discussions with the support desk about WCG
running on laptops in the organizations. We tell them that we limit the cpu
use, but they report that the cpu use jumps around and interferes with other
applications and since they see it jumping around they ignore our statements.
Additionally, I get feedback like this "Just ran the nightly installer for
Ubuntu 13.04 [Raring Ringtail] onto my 64GB USB 3.0 memory drive and pulled
BOINC 7.0.27 from the repository. Connected WCG and had it load 8 HCC1.
Installed GKrellm to monitor temps. Set prefs to 50% CPU time, AND most
importantly, set Run Based on Preferences. Gkrellm shows a seasaw load and
temperatures alternating between 88C and 75C every other second. 88C is
unacceptable, 75C would be borderline. As I wrote before, I'd have to lower it
to 25% to get the top temp to go below 75C... preposterous and could as well not
run BOINC. Then switch to % of processors and set that to 50%. Continous top
temp of 93C which is not acceptable at all, Fan is going full-out.
Installed CPUFreq and knocked it down to 2.5 Ghz. The top temp is now 75C and
bottom 62C with a 50% CPU time setting. "
Based on this, I've seen the following requests:
* The interval for which the % runtime is computed needs to be much smaller
than it is now. At least less than a second, and given Peter's work,
perhaps it should be dynamically chosen based on the clock frequency of the
processor. Even if we can't get it to achieve the power saving settings
Peter identified, it would be good so that there isn't thermal cycling like
we are seeing reported. Additionally, when people use tools such as top or
task manager should see an even pacing steady % cpu use and not a usage that
is jumping around.
* We are getting a lot of feedback that % runtime should be separately
controllable for GPU tasks and CPU tasks.
What are your thoughts?
Kevin Reed
. . . . . . . . . . . . . . . . . . . . . . . . .
i b m i n t e r a c t i v e:: c h i c a g o
312 529 2802 office
[email protected] email
/You can also donate your computer's unused time. Visit
//http://www.worldcommunitygrid.org// to learn how./
_______________________________________________
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.
