Jump to content
jumperalex

CPU freq not stepping down

156 posts in this topic Last Reply

Recommended Posts

UPDATE 3 (by JonP)Sorry for editing someone else's post, but thought it'd be good to post an update here in the OP for others that are seeing this issue.  Eric has a potential fix that he shared further in this thread.  Here's the info:

 

In KVM mode, there might be a cpu scaling driver issue with certain hardware combinations.  One of those drivers is called Intel-Pstate.  This is the chosen driver if your Intel cpu is Sandy Bridge (2011) or newer.  On my Haswell-class cpu (i7-4771) the Intel-Pstate driver is too sensitive and seems to keep the cpu frequency near the max frequency even when idle but occasionally it does scale the frequency down.

 

You can disable the Intel-Pstate driver by editing your /boot/syslinux/syslinux.cfg and adding a intel_pstate=disable parameter to the append line below:

 

...

label unRAID OS

  menu default

  kernel /bzimage

  append intel_pstate=disable initrd=/bzroot

...

 

 

Save the file, stop the array and reboot unRAID.  Doing this on my Haswell machine caused it to use the acpi-cpufreq scaling driver instead of the intel_pstate one.  It scales the frequency down like a rockstar now!  Usually keeps it around 800MHz - 1000MHz during idle now.

 

On the flip side, my other test machine, a year older Intel cpu (i5-3470) was able to scale down to 1600MHz (minimum) pretty consistently when using the intel_pstate driver... but when I disabled intel_pstate then there wasn't a scaling driver available.  For some reason the acpi-cpufreq driver wasn't compatible with this cpu.  Your mileage may very.

 

Give this a try and let me know if it helps you.  Either way, if it helped or not, let me know which cpu you tried with this command:

grep -m 1 'model name' < /proc/cpuinfo

 

UPDATE 2: I spoke too soon and it seems there is indeed some sub-optimal configurations with regards to Intel CPU's and the KVM (not Xen?) environment. In either case, Limetech is aware and working the issue. There are also some tweaks to be found in this tread to possible help in the meantime.

 

UPDATE: this appears to only be a cosmetic issue in that the GUI is not polling the right place for data. Depending on if you are using Xen or not, there are methods (in this thread) to confirm that your CPU is in fact ramping up/down down as expected.

 

=================================

The subject really does say it all. My server specs are in my sig.  However, some additional info:

 

From the Dashboard I can see my cpu is running at full speed even when load is very low.

 

To confirm it was not just a GUI issue I went into the console to look at the cpu freq but I can't seem pull that info. Looking at my old GO file I can see I was touching "/sys/devices/system/cpu/cpufreq" to modify my ondemand parameters.  That folder is no longer present

 

Looking at http://docs.slackware.com/howtos:hardware:cpu_frequency_scaling I'd expect to see folders like /sys/devices/system/cpu/cpu*/cpufreq but there isn't.

 

Did something fail to get loaded into the kernel?

Share this post


Link to post

On v6 beta 10a I see these files but per core

 

ls -alh /sys/devices/system/cpu/cpu0/cpufreq/
total 0
drwxr-xr-x 2 root root    0 Dec  2 07:12 ./
drwxr-xr-x 8 root root    0 Dec  2 07:12 ../
-r--r--r-- 1 root root 4.0K Dec  2 07:12 affected_cpus
-r-------- 1 root root 4.0K Dec  2 07:12 cpuinfo_cur_freq
-r--r--r-- 1 root root 4.0K Dec  2 07:12 cpuinfo_max_freq
-r--r--r-- 1 root root 4.0K Dec  2 07:12 cpuinfo_min_freq
-r--r--r-- 1 root root 4.0K Dec  2 07:12 cpuinfo_transition_latency
-r--r--r-- 1 root root 4.0K Dec  2 07:12 related_cpus
-r--r--r-- 1 root root 4.0K Dec  2 07:12 scaling_available_governors
-r--r--r-- 1 root root 4.0K Dec  2 07:12 scaling_driver
-rw-r--r-- 1 root root 4.0K Dec  2 07:12 scaling_governor
-rw-r--r-- 1 root root 4.0K Dec  2 07:12 scaling_max_freq
-rw-r--r-- 1 root root 4.0K Dec  2 07:12 scaling_min_freq
-rw-r--r-- 1 root root 4.0K Dec  2 07:12 scaling_setspeed

Share this post


Link to post

Just to hop in here, I am also having the same issue.

There are at least 4 or more people in the release thread for v12 with the same issue, and I assume many more who have not noticed or reported it yet.

Share this post


Link to post

At first I thought I had the same issue but it seems more that dynamix is not reporting the correct number.  Looking at /proc/cpuinfo I see much different (lower) values than what dynamix is reporting.  I am not running with xen or kvm - this is a straight hardware install/setup

Share this post


Link to post

I saw the original posts in the announcement thread and then here, but nothing seems to have been confirmed either way.

 

So, is this a thing, or just a reporting issue?

Share this post


Link to post

Can anyone else confirm that this is purely a cosmetic issue?

 

It is.  My system actual cpu freqs are at proper idle levels.  CPU temp confirm it.

Share this post


Link to post

I saw the original posts in the announcement thread and then here, but nothing seems to have been confirmed either way.

 

So, is this a thing, or just a reporting issue?

 

On my system it is a dynamix reporting bug.

 

The system is switching frequencies and mostly hovers at the lowest speeds. Dynamix always shows the max frequency.

 

cat /proc/cpuinfo |egrep -i mhz

cpu MHz        : 1697.078

cpu MHz        : 1699.070

cpu MHz        : 1646.078

cpu MHz        : 1686.453

cpu MHz        : 1598.000

cpu MHz        : 1605.968

cpu MHz        : 1688.445

cpu MHz        : 1620.179

 

Are you in KVM or Xen mode?  These stats won't be accurate with Xen mode in the current beta.

 

Behind the scenes the dashboard CPU stats are pulled using this command:

awk '/^cpu MHz/ {print $4*1" MHz"}' /proc/cpuinfo

 

 

Share this post


Link to post

Hmmm

 

Having upgraded to b12 running

awk '/^cpu MHz/ {print $4*1" MHz"}' /proc/cpuinfo

or

cat /proc/cpuinfo |egrep -i mhz

boths shows all of my cpus pretty much pegged at 3400 MHz.

 

Which tallies with what Dynamix gui is showing. Dynamix is also showing cpu utilization in the low single digits (currently hovering between 1 and 4%).

 

Doesn't look like my cpus are stepping down. Am booted with the default KVM option and

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

shows powersave for all cores.

Share this post


Link to post

Hmmm

 

Having upgraded to b12 running

awk '/^cpu MHz/ {print $4*1" MHz"}' /proc/cpuinfo

or

cat /proc/cpuinfo |egrep -i mhz

boths shows all of my cpus pretty much pegged at 3400 MHz.

 

Which tallies with what Dynamix gui is showing. Dynamix is also showing cpu utilization in the low single digits (currently hovering between 1 and 4%).

 

Doesn't look like my cpus are stepping down. Am booted with the default KVM option and

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

shows powersave for all cores.

 

I would like to figure this out as well.  But if I'm not mistaken I read what eschultz wrote a bit differently, and I believe that

awk '/^cpu MHz/ {print $4*1" MHz"}' /proc/cpuinfo

is how the webgui is pulling the information (meaning it would also be wrong.)

 

Assuming that's what eschultz meant I've yet to see the a right way to check the cpu info under KVM so if anyone could provide that code I'd be greatful.

Share this post


Link to post

 

No, that is the correct way of getting CPU info under KVM (/proc/cpuinfo). It's XEN they have trouble with. Reread what was said.

 

That's not good then, that means that my CPU is also not stepping down properly.

Share this post


Link to post

Any reason for the excess step of multiplying by one? Is that for some AMD oddity?

 

Different processors give different resolution.

 

The multiplication is done to automatically round the numbers, e.g. 1500.000 becomes 1500.

 

Share this post


Link to post

Just an update on this, it's still on the to-do list to get resolved as well as the issue with drive spinning.  The only good thing I can say is that at least this isn't causing system instability.  I realize it's something we need to look into and resolve, but if there is a silver lining on this problem, it's that it's not causing crashing or any other issues.

Share this post


Link to post

Not only that, it is cosmetic only. It would be another thing if we actually weren't stepping down. In fact, I'll change the OP title accordingly.

Share this post


Link to post

In KVM mode, there might be a cpu scaling driver issue with certain hardware combinations.  One of those drivers is called Intel-Pstate.  This is the chosen driver if your Intel cpu is Sandy Bridge (2011) or newer.  On my Haswell-class cpu (i7-4771) the Intel-Pstate driver is too sensitive and seems to keep the cpu frequency near the max frequency even when idle but occasionally it does scale the frequency down.

 

You can disable the Intel-Pstate driver by editing your /boot/syslinux/syslinux.cfg and adding a intel_pstate=disable parameter to the append line below:

 

...

label unRAID OS

  menu default

  kernel /bzimage

  append intel_pstate=disable initrd=/bzroot

...

 

 

Save the file, stop the array and reboot unRAID.  Doing this on my Haswell machine caused it to use the acpi-cpufreq scaling driver instead of the intel_pstate one.  It scales the frequency down like a rockstar now!  Usually keeps it around 800MHz - 1000MHz during idle now.

 

On the flip side, my other test machine, a year older Intel cpu (i5-3470) was able to scale down to 1600MHz (minimum) pretty consistently when using the intel_pstate driver... but when I disabled intel_pstate then there wasn't a scaling driver available.  For some reason the acpi-cpufreq driver wasn't compatible with this cpu.  Your mileage may very.

 

Give this a try and let me know if it helps you.  Either way, if it helped or not, let me know which cpu you tried with this command:

grep -m 1 'model name' < /proc/cpuinfo

 

 

Share this post


Link to post

Hmm interesting. Back in early 6beta days there was an inverse version with AMD. It was not ramping up enough and was actually impacting parity checks. At first it seemed unbelievable that a 4-core 975 was unable to keep up even downclocked, but sure enough a tweak to the ondemand settings (I still have them commented out in my go script) ramped up the CPU during parity (but only just barely; you could see a dip occasionally) and parity ran at the same speed as when the governor was set to performance.

 

Not that it is really related, just an anecdote of how touchy cpu governors can't be.

Share this post


Link to post

Give this a try and let me know if it helps you.  Either way, if it helped or not, let me know which cpu you tried with this command:

 

I am running in plain unRAID mode and changing the driver does work for me; using an Intel Core i3-4130T processor.

 

It used to stay at max frequency all the time (I could see it drop to lower frequencies for very short periods), now it nicely scales down as it used to do.

 

Share this post


Link to post

Disabling intel_pstate works like a champ for me.

 

grep -m 1 'model name' < /proc/cpuinfo

returns

Intel(R) Xeon(R) CPU E3-1240 v3 @ 3.40GHz

 

Cpu's are now mostly sitting at 800Mhz and ramping up when necessary

Share this post


Link to post

Hmm interesting. Back in early 6beta days there was an inverse version with AMD. It was not ramping up enough and was actually impacting parity checks. At first it seemed unbelievable that a 4-core 975 was unable to keep up even downclocked, but sure enough a tweak to the ondemand settings (I still have them commented out in my go script) ramped up the CPU during parity (but only just barely; you could see a dip occasionally) and parity ran at the same speed as when the governor was set to performance.

 

Not that it is really related, just an anecdote of how touchy cpu governors can't be.

I wonder of jphipps parity issues in non xen mode are the result of this?!  Maybe the same issue!?

Share this post


Link to post

possible. like i said, it was very surprising but the results were obvious and repeatable. I don't remember when the problem was fixed but a search of the change logs might point to when there was a change along the lines of ondemand settings, driver, or whatever.

Share this post


Link to post

In KVM mode, there might be a cpu scaling driver issue with certain hardware combinations.  One of those drivers is called Intel-Pstate.  This is the chosen driver if your Intel cpu is Sandy Bridge (2011) or newer.  On my Haswell-class cpu (i7-4771) the Intel-Pstate driver is too sensitive and seems to keep the cpu frequency near the max frequency even when idle but occasionally it does scale the frequency down.

 

You can disable the Intel-Pstate driver by editing your /boot/syslinux/syslinux.cfg and adding a intel_pstate=disable parameter to the append line below:

 

...

label unRAID OS

  menu default

  kernel /bzimage

  append intel_pstate=disable initrd=/bzroot

...

 

 

Save the file, stop the array and reboot unRAID.  Doing this on my Haswell machine caused it to use the acpi-cpufreq scaling driver instead of the intel_pstate one.  It scales the frequency down like a rockstar now!  Usually keeps it around 800MHz - 1000MHz during idle now.

 

On the flip side, my other test machine, a year older Intel cpu (i5-3470) was able to scale down to 1600MHz (minimum) pretty consistently when using the intel_pstate driver... but when I disabled intel_pstate then there wasn't a scaling driver available.  For some reason the acpi-cpufreq driver wasn't compatible with this cpu.  Your mileage may very.

 

Give this a try and let me know if it helps you.  Either way, if it helped or not, let me know which cpu you tried with this command:

grep -m 1 'model name' < /proc/cpuinfo

 

Hi eschultz,

Is working for me  ...

 

 

CPU on the server is.. ((Intel® Xeon® CPU E3-1270 v3 @ 3.50GHz))

 

The cpu was always around  (3500  3700MHz all the time)

now with this,

is all the way down to 800MHz and the load is 50-54 watts

Is all good!! 8) 8)

 

Mmm  let see what happens when the server is busy?

 

Thanks you, eschultz

                 

/hellboy

CPU.JPG.3b09aa91d7c0c90fdbbdb9f8b6a1925c.JPG

Share this post


Link to post

Give this a try and let me know if it helps you.  Either way, if it helped or not, let me know which cpu you tried with this command:

 

I am running in plain unRAID mode and changing the driver does work for me; using an Intel Core i3-4130T processor.

 

It used to stay at max frequency all the time (I could see it drop to lower frequencies for very short periods), now it nicely scales down as it used to do.

 

I also have an i3-4130T so I figure this fix will solve the issue for me as well. Will report back later when I can try this out.

 

Is the driver issue something which can/will be fixed in the next update? I don't mind implementing this quick fix, but I'd love it if I didn't have to.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.