December 2, 201411 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: 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?
December 2, 201411 yr 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
December 2, 201411 yr Author Right. Not seeing them at all on 12 Ninja edit: I must admit I didn't check for hidden. Yet.
December 2, 201411 yr 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.
December 3, 201411 yr 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
December 8, 201411 yr 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?
December 8, 201411 yr 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.
December 8, 201411 yr 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.
December 9, 201411 yr 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
December 10, 201411 yr 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.
December 10, 201411 yr 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.
December 10, 201411 yr 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.
December 10, 201411 yr 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.
December 11, 201411 yr 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.
December 11, 201411 yr Author 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.
December 12, 201411 yr 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
December 12, 201411 yr Author Hmm interesting. Back in early 6beta days there was an inverse version with AMD. It was not ramping up enough and was actually impacting parity checks. At first it seemed unbelievable that a 4-core 975 was unable to keep up even downclocked, but sure enough a tweak to the ondemand settings (I still have them commented out in my go script) ramped up the CPU during parity (but only just barely; you could see a dip occasionally) and parity ran at the same speed as when the governor was set to performance. Not that it is really related, just an anecdote of how touchy cpu governors can't be.
December 12, 201411 yr 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: I am running in plain unRAID mode and changing the driver does work for me; using an Intel Core i3-4130T processor. It used to stay at max frequency all the time (I could see it drop to lower frequencies for very short periods), now it nicely scales down as it used to do.
December 12, 201411 yr Disabling intel_pstate works like a champ for me. grep -m 1 'model name' < /proc/cpuinfo returns Intel(R) Xeon(R) CPU E3-1240 v3 @ 3.40GHz Cpu's are now mostly sitting at 800Mhz and ramping up when necessary
December 12, 201411 yr Hmm interesting. Back in early 6beta days there was an inverse version with AMD. It was not ramping up enough and was actually impacting parity checks. At first it seemed unbelievable that a 4-core 975 was unable to keep up even downclocked, but sure enough a tweak to the ondemand settings (I still have them commented out in my go script) ramped up the CPU during parity (but only just barely; you could see a dip occasionally) and parity ran at the same speed as when the governor was set to performance. Not that it is really related, just an anecdote of how touchy cpu governors can't be. I wonder of jphipps parity issues in non xen mode are the result of this?! Maybe the same issue!?
December 12, 201411 yr Author possible. like i said, it was very surprising but the results were obvious and repeatable. I don't remember when the problem was fixed but a search of the change logs might point to when there was a change along the lines of ondemand settings, driver, or whatever.
December 12, 201411 yr 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 Hi eschultz, Is working for me ... CPU on the server is.. ((Intel® Xeon® CPU E3-1270 v3 @ 3.50GHz)) The cpu was always around (3500 3700MHz all the time) now with this, is all the way down to 800MHz and the load is 50-54 watts Is all good!! 8) Mmm let see what happens when the server is busy? Thanks you, eschultz /hellboy
December 12, 201411 yr 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: I am running in plain unRAID mode and changing the driver does work for me; using an Intel Core i3-4130T processor. It used to stay at max frequency all the time (I could see it drop to lower frequencies for very short periods), now it nicely scales down as it used to do. I also have an i3-4130T so I figure this fix will solve the issue for me as well. Will report back later when I can try this out. Is the driver issue something which can/will be fixed in the next update? I don't mind implementing this quick fix, but I'd love it if I didn't have to.
Archived
This topic is now archived and is closed to further replies.