hi,

here's the scoop. i'm running ubuntu fiesty on my intel 1.7 ghz. i'm running a few boinc 5.4.11, projects (rosetta, and climate) which maxs out the cpu. now without any changes to the system i've noticed that my cpu won't go over 600Mhz running boinc. just happened the other day. it's like the intel sidesteps the chip down. weird. however when i'm running any other programs and the cpu needs everything its got the chip works just fine and will go up to the 1.7 ghz. but when that process is over it'll go back down to the 600 mhz while running boinc. now i know it might be a boinc related issue, however, nothing changed. so whatever i reinstalled the program just in case and that didn't solve the issue. i've looked all over so this is my last hope. any suggestions?

thanks,
ephman

Have you checked temps? To me it sounds like thermal throttling. But I agree it's odd that other CPU intensive programs work fine.

Maybe try running something like Prime95?

---

Kathryn :o)

Have you checked temps? To me it sounds like thermal throttling. But I agree it's odd that other CPU intensive programs work fine.

Maybe try running something like Prime95?

my temps ran a bit high when things were normal, around 64c @ 1.7ghz, now they're a steady 47C @ 600mhz. however, when i turn off and on my computer boinc never goes beyond the 600mhz now thus never allowing the chip to get hot enough to throttle back. i don't think that linux can remember what programs cause the chip to heat up and then on reboot remember to throttle back the cpu when boinc runs. i might be wrong. i upgraded to the latest 5.8.17, and still only giving out 600mhz, not the full 1.7ghz. when i run the cpu benchmark the chip then outputs the full 1.7ghz. haven't tried the prime yet. i told you this is a strange one.

thanks for the bandwidth,
ephman

---

I'm out of ideas then. I really don't know. Maybe a Linux guru will drop by.

---

Kathryn :o)

it might be because of the priority/nice level of the boinc apps - I believe speedstep will still throttle the CPU if the intensive task is only low priority. Could you turn speedstep off, or do you use speedstep when running on batteries?

---

it might be because of the priority/nice level of the boinc apps - I believe speedstep will still throttle the CPU if the intensive task is only low priority. Could you turn speedstep off, or do you use speedstep when running on batteries?

i don't want to turn speedstep off just yet. however for me to get the chip back up to the 1.7ghz i had to change the priority to normal from very low. seems to be working. things seem to be a little sluggish now however. i didn't want to do that because it's not a default setting from boinc, but anyhow we'll see how it works out.

thanks,
ephman

---

it might be because of the priority/nice level of the boinc apps - I believe speedstep will still throttle the CPU if the intensive task is only low priority. Could you turn speedstep off, or do you use speedstep when running on batteries?

i don't want to turn speedstep off just yet. however for me to get the chip back up to the 1.7ghz i had to change the priority to normal from very low. seems to be working. things seem to be a little sluggish now however. i didn't want to do that because it's not a default setting from boinc, but anyhow we'll see how it works out.

thanks,
ephman

found the solution. fiesty now supports frequency scaling... tada. had to make a few changes to change the setting from on demand to performance and that was it. solid 1.7ghz now all the time. sweet.

thanks,
ephman

---

As far as I know this is a long standing BOINC bug.

With intel Speedstep or AMD Cool&Quiet or PowerNow! enabled, BOINC apparently fails to trigger the corresponding CPU Power Management to ramp up clock levels (affects both Linux and Win32).

I've seen the respective Performance drops various times, after I forgot to either disable it or set the Power Management to "Performance"...
It seems the BOINC benchmarking does manage to trigger it in some Versions, but the Project Clients I have seen did not while running.

---

It seems the BOINC benchmarking does manage to trigger it in some Versions, but the Project Clients I have seen did not while running.

BOINC CC runs at normal priority (pri=0) at all times - including while it runs benchmarks. Well, perhaps some distributions change this behaviour, but Berkeley's BOINC does it like this. Project apps on the other hand run at lowest priority (pri=19).
IMHO it's actually a good thing that low priority applications don't cause CPU run at high frequency. That's intention for them being low priority - to consume only resources that would otherwise be wasted.

If one builds a mid-priority cruncher, then it's up to administrator of such machine to make appropriate changes to the CPU throttling policy.

---

Metod ...

But that would mean benchmarking at Performance Level X, but producing at X-60% depending on P-State achieved...

IMHO that's not a feature but a bug. That BOINC is supposed at low Priority is normal, but running at too low Priority to achieve full CPU performance should be reserved as an Option in the Preferences (e.g. "Grant running Projects Priority Level X when Idle, Level Y when in use"), not be the Default.

I would like the Idea of my machinery using lowest P-State e.g. after running out of work temporarily, but throttling back to full speed as work becomes available again. As it is now, because of that use of e.g. Cool&Quiet is not possible for me, although I would certainly like to have it turned on.

A bit Off-Topic, but use of User-Definable P-States would allow for excellent Throttling according to user-defined conditions. I'd love that one in Summer and make it dependent off Temperatures, for example.

---

But that would mean benchmarking at Performance Level X, but producing at X-60% depending on P-State achieved...

Well, BOINC does record fraction of time available to projects: <cpu_efficiency>. When new work is requested, this value is taken into account.

IMHO that's not a feature but a bug. That BOINC is supposed at low Priority is normal, but running at too low Priority to achieve full CPU performance should be reserved as an Option in the Preferences (e.g. "Grant running Projects Priority Level X when Idle, Level Y when in use"), not be the Default.

I would like the Idea of my machinery using lowest P-State e.g. after running out of work temporarily, but throttling back to full speed as work becomes available again. As it is now, because of that use of e.g. Cool&Quiet is not possible for me, although I would certainly like to have it turned on.

One of statements made by majority of projects is that project application will use only rest resources ... those resources that would otherwise be idle. Now, if your CPU would otherwise throttle to minimum frequency, that's fine. Actually it's up to you as user or host administrator to set up minimum machine performance and BOINC will happily use all that is available.

I second your idea about user being able to set run priority. It sould be set to lowest by default though. Implementation would be a bit tricky though. Windows only gives 6 possible settings, of those I'd only consider 3 safe (normal, low, lowest), while Unixes offer 40, of those 20 safe (from 0 to 19).

A bit Off-Topic, but use of User-Definable P-States would allow for excellent Throttling according to user-defined conditions. I'd love that one in Summer and make it dependent off Temperatures, for example.

BOINC has nothing to do with P states. As it does nothing to do with raw disk access, process scheduling and memory management. I'm not going to allow BOINC play with settings of my production machines. If you'd like to play with your, you're more than welcome to create cron jobs to play with system settings.

I'm running scheduled tasks on a couple of my machines suspending them during working hours. And I can't let BOINC do it automagicaly as there are not enough venues to choose between. You could similarly change P-states or whatever based on sensor readings, calendar and level of work cache...

---

Metod ...