CPU freq not stepping down


Recommended Posts

I have been doing some experimenting with the pstate driver and have some thoughts.  I can go to the command line and use  cat /proc/cpuinfo |egrep -i mhz and see the frequencies changing on the processors.  I believe the issue with the dashboard display is that the pstate driver changes frequencies so rapidly that the infrequent update of the dashboard is off.  Maybe it would be better to show the frequencies of the cpus in a different way.  Maybe averaging them over a period of time?  Or the lowest in a period of time?

 

The dashboard gives the impression of the pstate driver not working, when in fact it is.

 

Current implementation lets the display of the CPU frequencies update every 3 seconds, I can change that to update every 1 second, which may follow more accurately the frequency changes.

 

I think the point was that instead of displaying the singular cpu speed it needs to average the cpu speed over time.

 

However, I don't know if that will do anything as it sounds like how the UI queries the speed might be causing the speeds to shoot up to maximum levels.

 

Good point.  I find that the pstate driver is so sensitive and responsive, it cranks up the frequency very quickly.  Maybe a background check that wouldn't spike the frequency.

 

I need to experiment more to find the most 'suitable' solution, may need your help in testing. Thanks for bringing up these suggestions.

 

More than happy to help.  I'd like to see this solved because a lot of folks are panicking when they see spiked cpu frequencies.

Link to comment

I have been doing some experimenting with the pstate driver and have some thoughts.  I can go to the command line and use  cat /proc/cpuinfo |egrep -i mhz and see the frequencies changing on the processors.  I believe the issue with the dashboard display is that the pstate driver changes frequencies so rapidly that the infrequent update of the dashboard is off.  Maybe it would be better to show the frequencies of the cpus in a different way.  Maybe averaging them over a period of time?  Or the lowest in a period of time?

 

The dashboard gives the impression of the pstate driver not working, when in fact it is.

 

Current implementation lets the display of the CPU frequencies update every 3 seconds, I can change that to update every 1 second, which may follow more accurately the frequency changes.

 

I think the point was that instead of displaying the singular cpu speed it needs to average the cpu speed over time.

 

However, I don't know if that will do anything as it sounds like how the UI queries the speed might be causing the speeds to shoot up to maximum levels.

 

Good point.  I find that the pstate driver is so sensitive and responsive, it cranks up the frequency very quickly.  Maybe a background check that wouldn't spike the frequency.

 

I need to experiment more to find the most 'suitable' solution, may need your help in testing. Thanks for bringing up these suggestions.

 

More than happy to help.  I'd like to see this solved because a lot of folks are panicking when they see spiked cpu frequencies.

 

I ran this command on my test server and find the frequency going all over the place.  It does change to lower frequencies.

 

watch -n 1 'cat /proc/cpuinfo |egrep -i mhz'

 

It does not have much of a load and still goes high a lot.

 

On my main server that has Dockers and VMs running, it is staying high most of the time.

 

I think there are several issues here.  One is the sampling interval, and the other is that the pstate driver favors running the frequency very high most of the time.

 

My inclination right now is to show the lowest frequency over multiple samples.  Averaging will probably even favor a high frequency.

Link to comment

If nothing else we should make it clear to the casual observer that step down is expected and isnt working. God knows how many users are running 100% CPU for no reason other than they assume this is the norm for an OS now.

Link to comment

If nothing else we should make it clear to the casual observer that step down is expected and isnt working. God knows how many users are running 100% CPU for no reason other than they assume this is the norm for an OS now.

 

It does seem to be working.  The pstate driver is extremely sensitive on some processors (Haswell?) and tends to run frequencies high under even a small load.  The dashboard frequency display shows high values because of the way it is sampling and the fact that the pstate driver is so dynamic.

 

People may have an unrealistic expectation of lower frequencies on the display.

Link to comment

It appears that there is still some disagreement over weather this is actually an issue or not.

 

I'm in the camp that It's not actually scaling without Pstate disabled. This is not a display problem with the webgui.

 

You can see this behavior from the command line not just over the webgui.

Link to comment

If nothing else we should make it clear to the casual observer that step down is expected and isnt working. God knows how many users are running 100% CPU for no reason other than they assume this is the norm for an OS now.

 

It does seem to be working.  The pstate driver is extremely sensitive on some processors (Haswell?) and tends to run frequencies high under even a small load.  The dashboard frequency display shows high values because of the way it is sampling and the fact that the pstate driver is so dynamic.

 

People may have an unrealistic expectation of lower frequencies on the display.

 

Without the pstate change in the OP stepping down simply does not work for me. When I first posted I gave a cursory glace at the change v5 and v6 change logs and didn't see a fix either so I assumed it was still open hence the wording of my posts.

Link to comment

If nothing else we should make it clear to the casual observer that step down is expected and isnt working. God knows how many users are running 100% CPU for no reason other than they assume this is the norm for an OS now.

 

It does seem to be working.  The pstate driver is extremely sensitive on some processors (Haswell?) and tends to run frequencies high under even a small load.  The dashboard frequency display shows high values because of the way it is sampling and the fact that the pstate driver is so dynamic.

 

People may have an unrealistic expectation of lower frequencies on the display.

 

Without the pstate change in the OP stepping down simply does not work for me. When I first posted I gave a cursory glace at the change v5 and v6 change logs and didn't see a fix either so I assumed it was still open hence the wording of my posts.

 

Same. Without the pstate change in the OP my Intel Core i3-4130T runs at full throttle, and I say this having looked into it more then just looking at the WebGui.

Link to comment

This thread is almost entirely about Intel CPU's, so perhaps I should start another topic.  My old AMD is not stepping down either, appears to be stuck at max.  I'm quite sure I used to see 1000MHz now and then.  Syslog only mentions cpuidle, nothing more.  lsmod shows acpi_cpufreq, but I haven't seen any usage.  Have to admit, I haven't investigated this very thoroughly yet.

Link to comment

It appears that there is still some disagreement over weather this is actually an issue or not.

 

I'm in the camp that It's not actually scaling without Pstate disabled. This is not a display problem with the webgui.

 

You can see this behavior from the command line not just over the webgui.

 

The issue is different for different people and depends some on the processor family.  From what I have learned, the Sandy Bridge processors seem to work better that later processors like Haswell with the pstate driver.

 

The reason we are not able to get a firm grasp on this problem is that there are so many different things that can affect the cpu scaling.  e.g. scaling driver, processor family, and system load can all affect the idle frequency.  I hate to write off the pstate driver too fast, because it manages power on later processors much better than the acpi driver.  The cpu scaling driver manages the processor p-states and the newer processors are much better at power management than earlier processors.

 

If your goal is to see very low cpu frequencies, then disable the pstate driver.  If you want high performance, then leave the pstate driver.

 

I haven't done enough testing to see if there is much of a difference in power used with the different drivers.  My gut feel is that it is about the same on my main server that carries a constant load of 15-20%.

Link to comment
  • 3 months later...

This still a problem with 6.2 stable.

 

My i5-4460 never went below 3194mhz (3.2ghz) and after disabling intel_pstate it gets down to 800 frequently.

 

UPDATE: Here are my frequencies after turning off the pstate driver.

root@Tower:~# cat /proc/cpuinfo |egrep -i mhz
cpu MHz         : 1000.000
cpu MHz         : 800.000
cpu MHz         : 1100.000
cpu MHz         : 1000.000

Link to comment

Actually, speedstep is now finally working exactly as I think that it should on my i5-4440. I definitely had issues with my CPU never stepping down below 1600MHz on 6.1.9 stable. On 6.2 stable I'm back down to 800Mhz again:

root@Tower:~# cat /proc/cpuinfo |egrep -i mhz

cpu MHz        : 811.328

cpu MHz        : 800.187

cpu MHz        : 827.796

cpu MHz        : 800.066

Make sure that the unRAID HTML dashboard isn't open in a browser when polling the CPU frequencies. When this is open, and the CPU is working to push updates to it, my CPU speed is all over the place (1200-3100MHz). With it closed, and with the CPU truly at idle, the frequency immediately steps down to predominately run in the 800-900MHz range. In fact, it is rare to see it over go above 1200MHz. I never cared enough before to disable intel_psate on 6.1.9, but it still makes me happy to know that with 6.2 I don't even have to worry about disabling intel_psate and my power bill will still drop $0.50 from what it has been for the last few months.

Link to comment

not working for me either

 

root@Tower:~# cat /proc/cpuinfo |egrep -i mhz
cpu MHz         : 2833.250
cpu MHz         : 2833.250
cpu MHz         : 2833.250
cpu MHz         : 2833.250
cpu MHz         : 2833.250
cpu MHz         : 2833.250
cpu MHz         : 2833.250
cpu MHz         : 2833.250

Link to comment
  • 3 weeks later...

My server has an i7-4790 (Hashwell Refreh) With Unraid 6.2 its idle.

cat /proc/cpuinfo |egrep -i mhz
cpu MHz		: 1999.968
cpu MHz		: 1770.750
cpu MHz		: 3400.171
cpu MHz		: 1599.890
cpu MHz		: 1787.062
cpu MHz		: 2046.796
cpu MHz		: 1951.734
cpu MHz		: 902.390

This is with 2 VM's running continue..

 

But with the I5-4460 it didn't idle...

Link to comment

My i3-4160 is stepping down perfectly in unraid 6.2, both on the Dashboard and with the "cat /proc/cpuinfo |egrep -i mhz" command.

 

I clearly see all four available cores idling at around 0% on the Dashboard screen, even while it is open and cpuinfo reporting 800MHz speeds with the occasional core going up to around 1100MHz if something polls.

Link to comment
  • 2 months later...

I researched this issue because the Plugin "Fix Common Problems" listed my CPU possibly will not throttle down frequency at idle. I made the change to the syslinux.cfg file, saved, verified the change and rebooted but my i7-860 Lynnfield is still running at full 2.8 GHz when at idle. I am running a newly built 17 drive Unraid 6.2.4. Reading the replies the solution will not come easy due to the many different CPUs. I will keep my fingers crossed and thank you!

 

cat /proc/cpuinfo |egrep -i mhz

cpu MHz        : 2797.996

cpu MHz        : 2797.996

cpu MHz        : 2797.996

cpu MHz        : 2797.996

cpu MHz        : 2797.996

cpu MHz        : 2797.996

cpu MHz        : 2797.996

cpu MHz        : 2797.996

 

Snap_2016-12-08_at_15_14_46.jpg.10b56a77a8a75e1721603b95f4cf98af.jpg

Link to comment

I researched this issue because the Plugin "Fix Common Problems" listed my CPU possibly will not throttle down frequency at idle.

Just as a background that might help, that test was suggested by RobJ, and is simply the output of the command
cpufreq-info -d

If there is no output from that command, then FCP flags it as a possibility that the CPU will never step down.

Link to comment
  • 1 month later...

Yeah i agree this is still an issue on 6.2.4

 

without pstates off i get 4ghz min but with pstates turned off i get

cat /proc/cpuinfo |egrep -i mhz
cpu MHz         : 4001.000
cpu MHz         : 800.000
cpu MHz         : 1300.000
cpu MHz         : 1000.000
cpu MHz         : 4001.000
cpu MHz         : 800.000
cpu MHz         : 1000.000
cpu MHz         : 1000.000

cat /proc/cpuinfo |egrep -i mhz
cpu MHz         : 2400.000
cpu MHz         : 800.000
cpu MHz         : 1000.000
cpu MHz         : 1000.000
cpu MHz         : 4001.000
cpu MHz         : 800.000
cpu MHz         : 800.000
cpu MHz         : 1000.000

 

root@CY-HV:~# grep -m 1 'model name' < /proc/cpuinfo

model name      : Intel® Core i7-4790K CPU @ 4.00GHz

 

proper scaling, the problem for me is without pstates on i don't get my custom overclock of 4.7ghz

 

any suggestions?

 

EDIT: this is my freqs with unraid doing the same things as it was when pstates was disabled, but running way higher.

cat /proc/cpuinfo |egrep -i mhz
cpu MHz         : 4699.843
cpu MHz         : 4697.968
cpu MHz         : 4699.843
cpu MHz         : 4700.156
cpu MHz         : 4699.843
cpu MHz         : 4704.375
cpu MHz         : 4700.000
cpu MHz         : 4700.000

Link to comment
  • 11 months later...

Up until a day ago, I don't think I had a problem with the CPU frequency stepping down.  I am somewhat new to all of this, but my system was running what I'll call "normally".  Last night, the power went out for an hour or so, and upon restarting my server, the fan(s) seems to run at high/full speed all of the time (which is much noisier as well!).  Prior to the power outage, the fan(s) would only run full speed for about 10 seconds or so after a boot. 

 

The fix common problems plugin now indicates "Your CPU is running constantly at 100% and will not throttle down when it's idle".  If memory serves, that message was something like "Your CPU may not throttle down ...."  prior to the power outage.  So, I've been trying to find a CPU scaling driver - and that has led me to this thread.

 

I've checked my server machine BIOS and all seems to be "normal".   I don't see a SpeedStep setting, but I assume that "Deep C-State" is the same (at least based on the setting description in the BIOS); therefore, I've left that enabled.

 

My command line results are as follows:

grep -m 1 'model name' < /proc/cpuinfo
     Intel(R) Xeon(TM) CPU 3.20GHz        ## Intel Server Board S5000PSL motherboard ##
     

awk '/^cpu MHz/ {print $4*1" MHz"}' /proc/cpuinfo
     3191.87 MHz
     3191.87 MHz
     3191.87 MHz
     3191.87 MHz
     3191.87 MHz
     3191.87 MHz
     3191.87 MHz
     3191.87 MHz
     
     
cat /proc/cpuinfo |egrep -i mhz
     cpu MHz         : 3191.873
     cpu MHz         : 3191.873
     cpu MHz         : 3191.873
     cpu MHz         : 3191.873
     cpu MHz         : 3191.873
     cpu MHz         : 3191.873
     cpu MHz         : 3191.873
     cpu MHz         : 3191.873

 

The UnRAID GUI shows:

 

iggZMoZm.png

 

 

Is my next step to edit syslinux.cfg and add the pstate=disabled line?  If so, where might I find the syslinux.cfg file.  So far, I've been unable to locate it.

 

 

**Edit 1:  Reduced size of the embedded image

**Edit 2:  I have located the file and will see what the edit does ... 

 

Edited by ATEglauer
Link to comment

r u guys using 6.4? I also thought it wont throttle down, but it was. On 6.4 atleast. If nothing is done my u3 now only takes 65 watt incl. USP

 

Edit: found my thread:

 

Whats the reason some ppl still use old versions of unraid? 

Edited by nuhll
Link to comment
  • 5 weeks later...

Hi, I'm having the issue of my CPU frequency not scaling down too. I've tried the intel_pstate=disable in syslinux.cfg to no avail. I've also tried toggling all power/scaling related functions in the BIOS with intel_pstate enabled and disabled. Can't figure out a solution. 

 

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

model name      : Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz

 

If anyone has a solution for this generation of Xeons it would be greatly appreciated.

 

Thanks!

Link to comment

Try this: 

#!/bin/bash

echo "CPU 1: $(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq)"
echo "CPU 2: $(cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq)"
echo "CPU 3: $(cat /sys/devices/system/cpu/cpu2/cpufreq/scaling_cur_freq)"
echo "CPU 4: $(cat /sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_freq)"
Link to comment

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.