CPU freq not stepping down


156 posts in this topic Last Reply

Recommended Posts

For me this is not fixed in unRaid 6.0.1.

 

I am using an Intel i5-4570T on a Gigabyte GA-H87M-HD3.

 

On stock unRaid the CPU running at something like 3,4GHz all the time. Doesn't matter if i check it from the WebGUI or the command line.

 

If i put the intel_pstate=disable into the syslinux.cfg the CPU clocks down to the min of 800MHz, without saving more than 1W compared to the stock unRaid. On the other hand the turbo does not work anymore. Even with full load the cpu does not go above 2.9GHz.

 

So the problem is not solved and it would be great if the guys at Limetech could have a look at it. 

Link to post
  • Replies 155
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

These older models use the acpi-cpufreq driver, no config is necessary in unRAID, you just need to have SpeedStep enable in the bios, e.g.:   grep -m 1 'model name' < /proc/cpuinfo model

Posted Images

For me this is not fixed in unRaid 6.0.1.

 

I am using an Intel i5-4570T on a Gigabyte GA-H87M-HD3.

 

On stock unRaid the CPU running at something like 3,4GHz all the time. Doesn't matter if i check it from the WebGUI or the command line.

 

If i put the intel_pstate=disable into the syslinux.cfg the CPU clocks down to the min of 800MHz, without saving more than 1W compared to the stock unRaid. On the other hand the turbo does not work anymore. Even with full load the cpu does not go above 2.9GHz.

 

So the problem is not solved and it would be great if the guys at Limetech could have a look at it.

 

We haven't been able to track anything down with this just yet and some have reported that the dashboard being open is causing their CPUs to jump, but that command line tools (like the post after yours) are indicating that things are fine. 

 

The reality is that while this is something we'd like to see resolved for all, it's not as high of a priority item as other issues which are more pressing and affect a wider audience.

 

We keep our eyes open for kernel patches and try different things once and a while as we find the time, but so far, nothing has changed.

Link to post
  • 2 weeks later...

+1 in the p_state disable club. Now:

 


[b]driver: acpi-cpufreq[/b]
  CPUs which run at the same hardware frequency: 3
  CPUs which need to have their frequency coordinated by software: 3
  maximum transition latency: 10.0 us.
  hardware limits: 800 MHz - 3.70 GHz
  available frequency steps: 3.70 GHz, 3.50 GHz, 3.30 GHz, 3.10 GHz, 2.90 GHz, 2.70 GHz, 2.50 GHz, 2.30 GHz, 2.20 GHz, 2.00 GHz, 1.80 GHz, 1.60 GHz, 1.40 GHz, 1.20 GHz, 1000 MHz, 800 MHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance
  current policy: frequency should be within 800 MHz and 3.70 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz (asserted by call to hardware).
  cpufreq stats: 3.70 GHz:1.00%, 3.50 GHz:0.02%, 3.30 GHz:0.10%, 3.10 GHz:0.12%, 2.90 GHz:0.06%, 2.70 GHz:0.11%, 2.50 GHz:0.11%, 2.30 GHz:0.35%, 2.20 GHz:0.65%, 2.00 GHz:0.98%, 1.80 GHz:0.80%, 1.60 GHz:1.23%, 1.40 GHz:2.60%, 1.20 GHz:1.64%, 1000 MHz:5.44%,[b] 800 MHz:84.78%[/b]  (833)


 

 

Thanks for helping!

Link to post
  • 2 weeks later...

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:

 

Thanks Jon and Eric! Disabling intel_pstate worked like a charm for my Intel® Core i7-4785T CPU @ 2.20GHz. All my cores are now throttling back to 800MHz again.

 

Link to post
  • 1 month later...

I upgraded my unRAID server over the weekend and installed a Gigabyte GA-Z97N Wifi Motherboard with a Haswell i5-4590 CPU.  I noted the CPU scaling issue.  In the GUI the CPU is always at turbo frequency of ~3600-3700 MHz whereas with my prior Ivy Bridge i5-3340 CPU, it would scale down significantly when idle.  If I close the GUI and check via command line the frequency on all Haswell cores bounces all over the place like a yo-yo.  Sometimes it throttles back to 800-1000 MHz on all cores but if I check again 10 seconds later it is back to 3700 MHz and the next check may show 2200-2300 MHz or 1600-1700 MHz, etc.  Perhaps a docker or plugin is using CPU from time to time in the background?

 

With GUI open, command line frequency check shows the same yo-yo pattern of frequencies so the GUI being open does not cause the CPU to stay at turbo frequencies even though that is what is always reported via the GUI.  What I do notice with the GUI open is that the variance in frequencies across all cores is much greater.  A couple may be at 900~ while others are at ~1500 MHz, or one will be at 1500MHZ, two around 2200 MHz and one at turbo speed. With GUI open command line check shows cores at turbo speed more frequently.

 

Is what I am seeing "normal"? I do not have any KVM VMs.  Should I still try the intel_pstate=disable tweak in syslinux.cfg or is this normal behavior if I am running Plex, Cache Dirs, etc.?  It's not a huge issue, just curious as to what is the expected behavior.  Other than the MB/CPU change system config is the same as before and the prior config seemed to result in more CPU idling and almost never scaled to turbo unless a CPU intensive process was going. With the current hardware I see a lot more CPU speed fluctuations and way more turbo speeds even when little is going on to tax the CPU.

Link to post

I went ahead and added the intel_pstate=disable in syslinux.cfg with a dramatic improvement in both the GUI and command line reporting.  Although they are never both fully in sync (delay in reporting in GUI, I suppose), the GUI now shows the CPU cores throttling down to the expected 800 MHz on the Haswell chip and staying there more consistently instead of always being pegged at turbo speeds.  When speed increases it is now to the maximum 3300 MHz non-turbo speed of the chip instead of always ramping up to turbo speed of 3700 MHz.

 

Something is still causing frequent spikes (even with GUI closed) as observed on both the command line with the cpuinfo commmand and in the GUI (when open); however, speeds seem more consistent and reasonable now.  Unless it appear to cause some other issue, I will leave the intel_pstate=disable edit in syslinux.cfg as it appears to be "necessary" with my hardware.

Link to post

While I'm glad to hear your scaling is working better than prior, I am not certain that this issue is happening to you.

Do you happen to have a kill-a-watt to monitor wattage? Have you happened to notice any increased CPU temps?

 

For my situation I noticed both (i7-4790s), also I NEVER had reported speeds (GUI or SSH) less than max non turbo.

I have tried removing the intel_pstate=disable between releases, and always end up putting it back.

All 8 cores would stay at 3200 MHZ consistently (+- a couple of MHZ ex. 3197), no fluctuation.

Link to post

While I'm glad to hear your scaling is working better than prior, I am not certain that this issue is happening to you.

Do you happen to have a kill-a-watt to monitor wattage? Have you happened to notice any increased CPU temps?

 

For my situation I noticed both (i7-4790s), also I NEVER had reported speeds (GUI or SSH) less than max non turbo.

I have tried removing the intel_pstate=disable between releases, and always end up putting it back.

All 8 cores would stay at 3200 MHZ consistently (+- a couple of MHZ ex. 3197), no fluctuation.

 

Don't have a Kill-A-Watt.  CPU temps with and without the intel_pstate=disable edit are similar; between 36 to 38 at idle from both the command line and GUI, although, with the CPU spikes, they do jump higher. Removing intel_pstate=disable results in GUI (always) and command line (fluctuating) reporting turbo speeds. With it enabled, CPU throttling is reported in the GUI and more consistently and frequently through command line.

Link to post

Hoopster is not alone. I'm still running with intel_pstate=disabled because otherwise the system always run at the higher turbo speeds when the UI is open, and sometimes at higher speeds when periodically checking from the command line.

 

Yes, certainly still an issue just doesn't seem to be as widespread lately as the initial postings.

 

Link to post
  • 1 month later...

My new  ASRock E3C224D4I-14S is showing the same behavior. Only stepping down when I have intel_pstate=disabled added (see below). It is running at max. speed without this no matter if the dashboard is open or not.

 

root@Tower:~# grep -m 1 'model name' < /proc/cpuinfo
model name	: Intel(R) Xeon(R) CPU E3-1241 v3 @ 3.50GHz

 

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

 

root@Tower:~# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
ondemand
ondemand
ondemand
ondemand
ondemand
ondemand
ondemand
ondemand

 

Not a big deal but LT might need feedback what's working and what's not.

Link to post
  • 1 month later...
  • 2 months later...

Adding "intel_pstate=disable" to the config file works great. My core i3 4170 runs allways at 3,7Ghz full speed and now it is scaling down to 800Mhz.

 

Do you see the scale down in the Dashboard or command line?

 

Link to post
  • 2 months later...

Hi,

I'm new here and for Unraid as well.

I'm using latest stable version at this moment 6.1.9 and I'm glad to report that disabling pstate works for me.

I use a 4790 for the server and it steps back to 800 MHz instead of over 3800 before.

 

Thank you for this useful info and for a great community.

Link to post

I assumed when this thread was marked as solved it had been fixed in the OS. Manual fix works quite well for me too:

 

grep -m 1 'model name' < /proc/cpuinfo
model name      : Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz

 

Before

 

cat /proc/cpuinfo |egrep -i mhz
cpu MHz         : 3430.250
cpu MHz         : 3401.000
cpu MHz         : 3421.375
cpu MHz         : 3439.875

 

cat /proc/cpuinfo |egrep -i mhz
cpu MHz         : 3452.125
cpu MHz         : 3428.375
cpu MHz         : 3411.000
cpu MHz         : 3417.125

 

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

 

After

 

cat /proc/cpuinfo |egrep -i mhz
cpu MHz         : 1900.000
cpu MHz         : 1600.000
cpu MHz         : 3201.000
cpu MHz         : 1600.000

 

cat /proc/cpuinfo |egrep -i mhz
cpu MHz         : 1600.000
cpu MHz         : 1700.000
cpu MHz         : 2100.000
cpu MHz         : 1600.000

 

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

 

I cant seem to get it below 1600.000 any other tips?

Link to post

What does scaling available frequencies say ?

# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
2900000 2800000 2600000 2500000 2300000 2200000 2100000 1900000 1800000 1600000 1500000 1400000 1200000 1100000 900000 800000

Link to post

I dont have that file but i suspect this is the same for a core

 

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies

3201000 3200000 3100000 3000000 2900000 2700000 2600000 2500000 2400000 2300000 2200000 2100000 1900000 1800000 1700000 1600000

 

that seems to tie up to what I have seen. I will need to google, unless anyone knows, if these numbers come from the CPU itself or something else.

 

Thanks for the pointer.  ;D

Link to post

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.

 

Link to post

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.

 

Link to post

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.

 

That might help.  The one thing I noticed is that the frequency with the pstate driver really bounces around a lot.  It is really dynamic.

 

I'm not sure how you are sampling the frequency, but maybe take several samples over a short time and use the lowest value to display.

 

Let me know if I can do any testing for you.

Link to post

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.

Link to post

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.

 

 

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.