Thanks. Our needs are not pressing.
(*Btw -- my reason for asking wasn't related to energy, but rather usability: A certain number of volunteers freak when they see their activity monitor sawtooth between zero and 100. it looks broken; and it looks like it regularly "exceeds" the promised CPU throttle, etc. so my interest is that, when this is implemented, a client set to have a CPU throttle of 60% will appear to show the same in the windows system activity monitor. [?]) On Nov 7, 2013, at 2:04 PM, David Anderson <[email protected]> wrote: > 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.
