jumperalex

CPU freq not stepping down

168 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

Right.  Not seeing them at all on 12

 

Ninja edit: I must admit I didn't check for hidden. Yet.

 

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

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.

Share this post


Link to post

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

 

My 2nd box runs Xen so don't want to upgrade if this is an actual 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

 

 

dynamix_cpu_temp_bug.png.ade049befb2f6a6423304d0670c5c792.png

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

@eschultz,

 

I'm in the default boot selection mode of unRAID, so that should be KVM.

 

Perhaps there's also items that are done on a page refresh that forces the cpu to spin up, like say forking off a bunch of parallel processes like smartctls ?

 

These were done at as close a timeframe as humanly possible:

core 1 / 2 2483.33 MHz 1879.3 MHz

core 3 / 4 2308.55 MHz 1783.14 MHz

core 5 / 6 2137.62 MHz 2137.48 MHz

core 7 / 8 1599.99 MHz 2126.2 MHz

root@REAVER:~# awk '/^cpu MHz/ {print $4*1" MHz"}' /proc/cpuinfo

1599.86 MHz

1612.21 MHz

1599.86 MHz

1623.5 MHz

2282.38 MHz

2137.48 MHz

1599.99 MHz

1599.99 MHz

 

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

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

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

 

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

 

Surely the following produces better looking results (they're all exactly aligned the same) and with less work being done?

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

1658.695 MHz

1600.125 MHz

1696.546 MHz

1862.960 MHz

1599.992 MHz

1599.726 MHz

1993.117 MHz

1599.859 MHz

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.

 

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.

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

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.

 

but then all the frequencies do not align, which looks worse .

 

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.

 

I find this gives better looking results since it rounds the numbers and aligns identically.

 

awk '/^cpu MHz/ {printf"%4.0f MHz\n", $4}' /proc/cpuinfo

 

cpu_align.png.5087fb1e82a1f6f2f14f5dcc0b71e517.png

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

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


Copyright © 2005-2018 Lime Technology, Inc.
unRAID® is a registered trademark of Lime Technology, Inc.