February 19, 201511 yr I think the problem is just confined to the Haswell processors, not Ivy Bridge Xeons. Hmmm ... so why do I always see one core (virtual, not physical) running at maximum clock rate? Seems to be a function of Docker, in my experience. I don't use VMs, but I do use Docker. Even on the FX8320E/760G I see each core in turn going up to 3200MHz for a split second, while all the others sit at 1400MHz. I don't see much/any change in power consumption, though. On the Haswell machines, all the cores are pegged at full speed, and power consumption goes up significantly from it's true idling consumption.
February 19, 201511 yr Peter - I suspect that one core is held at (or near) full speed when you are observing the UI because there are polling tasks from the UI requesting status info and that is enough to hold one thread active. This is speculation but seems plausible.
February 19, 201511 yr Peter - I suspect that one core is held at (or near) full speed when you are observing the UI because there are polling tasks from the UI requesting status info and that is enough to hold one thread active. This is speculation but seems plausible. Yes, I did wonder whether the simple act of displaying the info was sufficient to run one core at full speed - the observer effect.
February 19, 201511 yr Peter - I suspect that one core is held at (or near) full speed when you are observing the UI because there are polling tasks from the UI requesting status info and that is enough to hold one thread active. This is speculation but seems plausible. Yes, I did wonder whether the simple act of displaying the info was sufficient to run one core at full speed - the observer effect. Maybe but that's an awful lot of processing power for what ought to be a rather simple task. I think this might signify some sort of issue with Ivy Bridge as well, but perhaps not the same exact issue.
February 20, 201511 yr I'm using my Kill-A-Watt to monitor the CPU load, and it's still using a lot of power if I have no Dashboards open. The CPU fan's constant higher speed is another sign. I'm confident it's not the observer effect.
February 21, 201511 yr Author jonp: so I thought Xen should be showing me the right cpu speed. That is xl top. It is showing full freq speed. My config is in my sig. So how sure are we this is only a haswell issue?
February 23, 201511 yr jonp: so I thought Xen should be showing me the right cpu speed. That is xl top. It is showing full freq speed. My config is in my sig. So how sure are we this is only a haswell issue? Might be a Xen issue. I know on Windows if you're running Hyper-V, Task Manager only shows the top speed of the chip, even though it is still throttling (as shown by CPU-Z or similar). Maybe Xen does the same to linux?
February 23, 201511 yr jonp: so I thought Xen should be showing me the right cpu speed. That is xl top. It is showing full freq speed. My config is in my sig. So how sure are we this is only a haswell issue? Might be a Xen issue. I know on Windows if you're running Hyper-V, Task Manager only shows the top speed of the chip, even though it is still throttling (as shown by CPU-Z or similar). Maybe Xen does the same to linux? This issue affects all boot modes as far as we can tell.
February 24, 201511 yr Here's something interesting. Test system: MSI B85M-Eco with i3-4350. Idles at 3600MHz on 4 'cores'. 38W at the wall with all drives spinning. Turn off Hyperthreading, now idles at 2100MHz on 2 'cores'. Still 38W at the wall which to me says with HT on it was idling OK, but just reporting wrongly. So without HT, it seems to report frequency OK. With HT it doesn't.
February 25, 201511 yr Here's something interesting. Test system: MSI B85M-Eco with i3-4350. Idles at 3600MHz on 4 'cores'. 38W at the wall with all drives spinning. Turn off Hyperthreading, now idles at 2100MHz on 2 'cores'. Still 38W at the wall which to me says with HT on it was idling OK, but just reporting wrongly. So without HT, it seems to report frequency OK. With HT it doesn't. Interesting. Is that the normal range for that proc (2100 - 3600)? The haswells we have scale from 800MHz to 3.x GHz (the x varies based on the exact model proc).
March 4, 201511 yr Here's something interesting. Test system: MSI B85M-Eco with i3-4350. Idles at 3600MHz on 4 'cores'. 38W at the wall with all drives spinning. Turn off Hyperthreading, now idles at 2100MHz on 2 'cores'. Still 38W at the wall which to me says with HT on it was idling OK, but just reporting wrongly. So without HT, it seems to report frequency OK. With HT it doesn't. Interesting. Is that the normal range for that proc (2100 - 3600)? The haswells we have scale from 800MHz to 3.x GHz (the x varies based on the exact model proc). No, it normally idles at ~800MHz running Windows. But, disabling HT means it's not (possibly) running at 3600MHz all the time.
April 30, 201511 yr Completely edited this post with supporting details in case anyone searches for this problem as this thread was not the easiest to find when I googled. It does appear that my cpu speeds/power consumption are where they should be just the reporting in the dashboard for cpu speed is incorrect: *Supporting details* Issue: I've been noticing that on dashboard, my system reports that my system's 4 cores are usually around 2400mhz or higher even when idling. My CPU should idle at 1600mhz. Testing First I though it might be the cachedirs plugin or my Dockers causing this. Turning them off did not really impact the Dashboard cpu speeds and they still tended to hover around 2400mhz. Next I tried also spinning down my data array but this also had negligible impact cpu speed, which still hovered loosely around 2400mhz. Finally I checked the system's power draw; My unRaid NAS also shows about 32watts of power draw as measured by a Kill-a-Watt which is I think is about as low as I can expect while idling and data array spun down (but dockers/plugins still running). As the Dashboard appeared to be incorrect, I SSH'd into unRaid and executed the following a couple times to confirm: cat /proc/cpuinfo | grep MHz root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 1617.656 cpu MHz : 1627.882 cpu MHz : 1678.750 cpu MHz : 1648.601 root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 1650.992 cpu MHz : 1612.609 cpu MHz : 1641.695 cpu MHz : 1653.250 root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 1659.890 cpu MHz : 1691.500 cpu MHz : 1697.210 cpu MHz : 1699.203 root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 1662.945 cpu MHz : 1600.125 cpu MHz : 1604.640 cpu MHz : 1631.070 Ultimately: My system is idling properly and power draw seems inline with what I can expect. The Dashboard is just reporting cpu speeds much higher than they really are. So probably a bug, but (for me) not critical as it's working correctly behind the scenes. Thanks!
April 30, 201511 yr We are starting to think this is just a reporting error, not actually a real issue with CPU scaling at all. We witnessed the processor entering a C7 state even though it was reporting full clockspeed, which to us is indicating that nothing is really broken.
May 23, 201511 yr Just tried UnRAID 6rc3 on an E3-1270v3 on an AsRock E3C226-V+ and it's reporting speed OK.
May 24, 201511 yr I have just tried the "cat /proc/cpuinfo | grep MHz" command on my Haswell i3-4160 with and without the intel_pstate in the config with all drives spun down and can offer the following feedback... WITH intel_pstate=disable, three cores tend to hover at about 800MHz and one will flutter from 1200 to 3600. WITHOUT intel_pstate=disable (after reboot), all 4 cores seem to balance at either around 800-900 or all around 3000-3600. It was about 50:50 which you would get. I then realised that I had the browser open at the Dashboard to check the results against what was reported. The browser only ever reported the higher value range when it refreshed and would sit on around 3600 all the time with the occasional dip lower on one core. I closed the browser and reran the "cat /proc/cpuinfo | grep MHz" and saw that the reported values immediately slam back down to the 800-900 range and were consistent at this range, never spiking above it at all. It seems that the Dashboard is holding the core frequencies high and is only reporting the higher range whenever it polls. Scroll the CODE block to see all results. Browser OPEN root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 3600.000 cpu MHz : 3600.000 cpu MHz : 3601.968 cpu MHz : 3600.000 root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 799.875 cpu MHz : 915.468 cpu MHz : 997.593 cpu MHz : 965.953 root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 3599.859 cpu MHz : 3600.562 cpu MHz : 3600.000 cpu MHz : 3600.140 root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 900.000 cpu MHz : 899.156 cpu MHz : 815.484 cpu MHz : 897.750 root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 3500.156 cpu MHz : 3498.750 cpu MHz : 3494.812 cpu MHz : 3500.859 root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 2643.750 cpu MHz : 1698.328 cpu MHz : 1604.812 cpu MHz : 1699.875 Browser CLOSED root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 899.015 cpu MHz : 897.609 cpu MHz : 900.140 cpu MHz : 800.015 root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 880.312 cpu MHz : 899.859 cpu MHz : 900.140 cpu MHz : 897.609 root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 976.921 cpu MHz : 998.718 cpu MHz : 1000.125 cpu MHz : 813.796 root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 799.875 cpu MHz : 808.171 cpu MHz : 824.203 cpu MHz : 805.218 root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 835.031 cpu MHz : 903.937 cpu MHz : 852.750 cpu MHz : 991.687 cpu MHz : 899.437 root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 900.000 cpu MHz : 900.000 cpu MHz : 832.640 cpu MHz : 800.015 Having the Dashboard open is like having the boss in the room - everyone works flat out... until the SOB walks back into his office and shuts the door when the chatter and idleness resumes.
May 29, 201511 yr I have just tried the "cat /proc/cpuinfo | grep MHz" command on my Haswell i3-4160 with and without the intel_pstate in the config with all drives spun down and can offer the following feedback... WITH intel_pstate=disable, three cores tend to hover at about 800MHz and one will flutter from 1200 to 3600. WITHOUT intel_pstate=disable (after reboot), all 4 cores seem to balance at either around 800-900 or all around 3000-3600. It was about 50:50 which you would get. I then realised that I had the browser open at the Dashboard to check the results against what was reported. The browser only ever reported the higher value range when it refreshed and would sit on around 3600 all the time with the occasional dip lower on one core. I closed the browser and reran the "cat /proc/cpuinfo | grep MHz" and saw that the reported values immediately slam back down to the 800-900 range and were consistent at this range, never spiking above it at all. It seems that the Dashboard is holding the core frequencies high and is only reporting the higher range whenever it polls. Scroll the CODE block to see all results. Browser OPEN root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 3600.000 cpu MHz : 3600.000 cpu MHz : 3601.968 cpu MHz : 3600.000 root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 799.875 cpu MHz : 915.468 cpu MHz : 997.593 cpu MHz : 965.953 root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 3599.859 cpu MHz : 3600.562 cpu MHz : 3600.000 cpu MHz : 3600.140 root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 900.000 cpu MHz : 899.156 cpu MHz : 815.484 cpu MHz : 897.750 root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 3500.156 cpu MHz : 3498.750 cpu MHz : 3494.812 cpu MHz : 3500.859 root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 2643.750 cpu MHz : 1698.328 cpu MHz : 1604.812 cpu MHz : 1699.875 Browser CLOSED root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 899.015 cpu MHz : 897.609 cpu MHz : 900.140 cpu MHz : 800.015 root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 880.312 cpu MHz : 899.859 cpu MHz : 900.140 cpu MHz : 897.609 root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 976.921 cpu MHz : 998.718 cpu MHz : 1000.125 cpu MHz : 813.796 root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 799.875 cpu MHz : 808.171 cpu MHz : 824.203 cpu MHz : 805.218 root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 835.031 cpu MHz : 903.937 cpu MHz : 852.750 cpu MHz : 991.687 cpu MHz : 899.437 root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 900.000 cpu MHz : 900.000 cpu MHz : 832.640 cpu MHz : 800.015 Having the Dashboard open is like having the boss in the room - everyone works flat out... until the SOB walks back into his office and shuts the door when the chatter and idleness resumes. Daniel and HellDiver, thanks for reporting this. I can confirm the same on my system. Marking this one SOLVED!
May 29, 201511 yr using the above command on my supermicro MB, the cpus are all over the place like I would expect - but the dashboard never matches
May 29, 201511 yr using the above command on my supermicro MB, the cpus are all over the place like I would expect - but the dashboard never matches Good to know! This dashboard / webgui itself may be the reason the CPUs never look like they are clocking down. More important here is that they actually are stepping down.
June 5, 201511 yr For me on RC4, removing "intel_pstate=disable" and then running "cat /proc/cpuinfo | grep MHz" (at various different times and without dashboard open) always shows all cpus (cores) running at 3400MHz+ Adding "intel_pstate=disable" back in and they are back to dropping to 800MHz. The cpu is a Xeon E3-1240v3 on a Supermicro X10SL7-F motherboard. There are bios updates for the board that I haven't had chance to apply yet, it's running v1.1a and I see that v3 is the latest available, but I can't find anything to detail what the changes have been to see if there is anything relevant.
June 8, 201511 yr For me on RC4, removing "intel_pstate=disable" and then running "cat /proc/cpuinfo | grep MHz" (at various different times and without dashboard open) always shows all cpus (cores) running at 3400MHz+ Adding "intel_pstate=disable" back in and they are back to dropping to 800MHz. The cpu is a Xeon E3-1240v3 on a Supermicro X10SL7-F motherboard. There are bios updates for the board that I haven't had chance to apply yet, it's running v1.1a and I see that v3 is the latest available, but I can't find anything to detail what the changes have been to see if there is anything relevant. I would attempt two things: 1) The BIOS updates 2) Try the command line methods to reading CPU usage and see if they fluctuate better It appears this issue really is resolved, but that the way scaling occurs on more modern systems is different than the way we used to see it occur.
June 8, 201511 yr I would attempt two things: 1) The BIOS updates 2) Try the command line methods to reading CPU usage and see if they fluctuate better It appears this issue really is resolved, but that the way scaling occurs on more modern systems is different than the way we used to see it occur. jon, I will try the bios updates when I get the chance. But, I have already been using the command line methods to read usage - mentioned in my post - I'm not going by the web gui dashboard figures at all. Booting without the "intel_pstate=disable" the figures are always very high whereas with that in place, and the server in the same state, the figures drop to expected levels.
June 11, 201511 yr I hate to do this, but.... I'm still not convinced this is actually fixed (for me anyway)... I'm not basing this on reporting of frequencies, I'm questioning it on power (watts) and temperature of my CPU. I have a kill-a-watt hooked up, and looked at it the other night, no active streams, 1 disc spinning, and I was at ~105w idle, CPU temps are reported as ~42C. So I decided to put back in intel_pstate=disable, updated to RC5 (not sure if you made any changes that would effect this from RC4) and rebooted. Waited 2 hours or so for the same disc to be spinning (it's shared in a W8 VM, to be expected), everything else spun down, no active streams. Kill-a-watt is showing 85-90 watts, ~32C!. The webUI is also reporting much lower values, however I don't even really look at those anyhow.... So more heat on the CPU (~10C hotter), and 15W extra at the plug.... Maybe the "s" Haswell I have is special....LOL, however there is still something not right. I wouldn't consider it solved, but clearly not a deal breaker at this point... Anything I can do to test, etc... I am more than up for it (have newest BIOS, etc...).
June 11, 201511 yr I hate to do this, but.... I'm still not convinced this is actually fixed (for me anyway)... ... Me too. Not that big issue, but... I'm on RC5 and using an AMD A6 dual core cpu. Even when system is totally idle (no disk spun up...) I ever got one of the two cores at max speed (3900 MHz in my case) since what reported by WebGUI. The most interesting part in that is the two cores alternate continuosly each other to be at max speed in turn. This behavior has been observed since RC3 (first one for me) and I have never seen nothing similar in Windows OS. Is there some settings I could try too (not being on Intel...)?
June 11, 201511 yr I hate to do this, but.... I'm still not convinced this is actually fixed (for me anyway)... ... Me too. Not that big issue, but... I'm on RC5 and using an AMD A6 dual core cpu. Even when system is totally idle (no disk spun up...) I ever got one of the two cores at max speed (3900 MHz in my case) since what reported by WebGUI. The most interesting part in that is the two cores alternate continuosly each other to be at max speed in turn. This behavior has been observed since RC3 (first one for me) and I have never seen nothing similar in Windows OS. Is there some settings I could try too (not being on Intel...)? I wouldn't trust the WebGUI report to be accurate, the best way to determine if your CPU isn't stepping down. Is going to command line and running. cat /proc/cpuinfo | grep MHz A couple of times at differnt times and seeing what it reports, both with the WebGUI open and with it closed... It's possible you have this issue but it might not be this problem exactly.
June 11, 201511 yr I wouldn't trust the WebGUI report to be accurate, the best way to determine if your CPU isn't stepping down. Is going to command line and running. cat /proc/cpuinfo | grep MHz A couple of times at differnt times and seeing what it reports, both with the WebGUI open and with it closed... It's possible you have this issue but it might not be this problem exactly. It could be. I'll surely doublecheck it this way... BUT it would be anyway a bug!
Archived
This topic is now archived and is closed to further replies.