May 30, 201610 yr 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.
May 30, 201610 yr 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.
May 31, 201610 yr 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.
May 31, 201610 yr 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.
May 31, 201610 yr 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.
May 31, 201610 yr 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.
May 31, 201610 yr 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.
May 31, 201610 yr 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.
May 31, 201610 yr 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%.
September 18, 20169 yr 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
September 19, 20169 yr 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.
September 19, 20169 yr Not working in my case. With almost no load (see screenshot): root@Tower:~# cat /proc/cpuinfo |egrep -i mhz cpu MHz : 3500.000 cpu MHz : 3500.000 cpu MHz : 3499.863 cpu MHz : 3499.863 cpu MHz : 3500.000 cpu MHz : 3500.000 cpu MHz : 3500.000 cpu MHz : 3499.863 When I launched the command web dashboard was closed.
September 19, 20169 yr 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
October 5, 20169 yr 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...
October 5, 20169 yr 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.
December 8, 20169 yr 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
December 8, 20169 yr 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.
December 9, 20169 yr Thank for your reply Squid. The command "cpufreq-info -d" did not return an output.
December 9, 20169 yr Thank for your reply Squid. The command "cpufreq-info -d" did not return an output. More reading: http://lime-technology.com/forum/index.php?topic=49463.15 (or search for cpufreq-info in the forums)
January 25, 20179 yr 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
January 12, 20188 yr 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: 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 January 12, 20188 yr by ATEglauer
January 12, 20188 yr 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 January 12, 20188 yr by nuhll
January 13, 20188 yr I am on 6.3.5 and am not given an option to update to 6.4 (at least that I know of!).
February 12, 20188 yr 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!
February 12, 20188 yr 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)"
Archived
This topic is now archived and is closed to further replies.