August 6, 201510 yr 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.
August 6, 201510 yr The cpuinfo command works perfectly on my i3-4160 on a GA-H97N-WIFI board. All 4 processes at 800MHz providing the Dashboard is not open. If you do open the dashboard of course they jump up to 100%.
August 7, 201510 yr 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.
August 21, 201510 yr +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!
August 31, 201510 yr 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.
October 5, 201510 yr 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.
October 5, 201510 yr 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.
October 6, 201510 yr 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.
October 6, 201510 yr 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.
October 6, 201510 yr 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.
November 20, 201510 yr 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.
December 25, 201510 yr Seems enabling EIST and stepping also causes unraid to ignore cores. (2) X Xeon x5690 with EIST/ stepping disabled. now same server w/ EIST/stepping enabled
December 26, 201510 yr No need to..... Maybe it was the holiday food coma.... I did not notice that when you change any of the EIST or stepping settings on my SuperMicro board it auto-disables simultaneous multithreading AKA hyper threading.
March 20, 201610 yr 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.
March 21, 201610 yr 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?
March 21, 201610 yr On the Dashboard. 2 cores at 800 MHz, 1 core at 1-1,4 Ghz and one around 3 Ghz in idle.
May 24, 201610 yr 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.
May 26, 201610 yr 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?
May 27, 201610 yr 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
May 27, 201610 yr 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.
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.
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.
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. 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.
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.
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.
Archived
This topic is now archived and is closed to further replies.