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.

 

Too early to tell.  Know that we would like to avoid this workaround as well.  The main purpose of providing it was to ensure that it results in a fix for folks and to see which processors are affected.

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.

 

Too early to tell.  Know that we would like to avoid this workaround as well.  The main purpose of providing it was to ensure that it results in a fix for folks and to see which processors are affected.

 

I think the kernel 3.18 or 3.19 has even more changes for the Intel pstate drivers. I can't recall exact details but do remember seeing it on the list when I was reading about latest Linux roadmaps.

 

I don't think we should jump to kernel 3.18 as it just hit and always seems to take a couple of release patches to get things running smoothly again. But just wanted to let everyone know how it seems to be a work in progress, though I'm sure the limetech folks already know this.

We won't roll 3.18 until btrfs progs are updated.

I recall in one of the past betas, I had to tweak the scaling driver parameters because parity checks were going slow due to CPU clock not staying at max.

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

 

This seems to be working! Thanks for the help!

grep -m 1 'model name' < /proc/cpuinfo

model name      : Intel® Core i3-4130T CPU @ 2.90GHz

 

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.

 

Too early to tell.  Know that we would like to avoid this workaround as well.  The main purpose of providing it was to ensure that it results in a fix for folks and to see which processors are affected.

 

I think the kernel 3.18 or 3.19 has even more changes for the Intel pstate drivers. I can't recall exact details but do remember seeing it on the list when I was reading about latest Linux roadmaps.

 

I don't think we should jump to kernel 3.18 as it just hit and always seems to take a couple of release patches to get things running smoothly again. But just wanted to let everyone know how it seems to be a work in progress, though I'm sure the limetech folks already know this.

 

Our current beta12 has kernel 3.17.4 and our next beta (still under development), Beta13, will be upgraded to kernel 3.17.6.  For kicks I tried Kernel 3.18 a couple days ago and the intel_pstate driver situation wasn't improved in either new kernel versions.  I probably need to roll back to beta10a (kernel 3.16.3) and see if that intel_pstate driver works on my test systems and review the kernel code changes between now and then.  I'm doubtful the next beta will include a intel_pstate fix since we're working to wrapping it up for you guys... there are 25-30 fixes and new features in Beta13.

 

Thanks to everyone so far on reporting back the cpu.  I'll be keeping a list of cpu's affected by the intel_pstate driver and try to find the code to blame in the kernel. 

i found something like this

 

http://kernel.opensuse.org/cgit/kernel-source/tree/patches.fixes/cpufreq_ondemand_performance_optimise_default_settings.patch?h=SLE12&id=513691b9277891ee87e799f1b873b170e72f9061

 

HW cpufreq drivers (e.g. all non-acpi AMD) may report too high latency values.

The default sampling rate (how often the ondemand/conservative governor

checks for frequency adjustments) may therefore be much too high,

resulting in performance loss.

 

Restrict default sampling rate to 300ms. 333ms sampling rate is field

tested with userspace governors, 300ms should be a fine maximum default

value for the ondemand kernel governor for all HW out there.

 

Set default up_threshold to 40 on multi core systems.

This should avoid effects where two CPU intensive threads are waiting on

each other on separate cores. On a single core machine these would all be

processed on one core resulting in higher utilization of the one core.

Nice work, yey for the return of CPU throttling! 

 

model name      : Intel® Core i7-4790S CPU @ 3.20GHz

 

I have applied the Intel_pstate change to my Haswell i3-4160 on a Gigabyte H97N-wifi with apparent success.

 

Instead of reporting 3500/3500, 3500/3500 while idle it now reports 3400/800, 800/800 or similar low power combinations such as 2500/800, 1000/800.

 

Let me know if you want anything checked in my BIOS or if you want edits to the .cfg files.

 

Subbed.

Just a quick update:  Last week I was able to track down the exact commit in the kernel that's causing the frequency issues on haswell-based cpus using the intel_pstate driver.  I created a kernel patch for Tom so, with his blessing, might actually make it in the next beta.  I also shot an email to the commit author at Intel to get his feedback on the situation and my findings. 

Excellent job, thanks for looking into this and resolve it

 

Brilliant! Would that mean we could undo the edit to the syslinux.cfg once you push the update?

Brilliant! Would that mean we could undo the edit to the syslinux.cfg once you push the update?

 

Yes 

More importantly, will Intel give you a bounty for doing this job.? Hahah I crank myself up sometimes

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

 

Thanks! Works fine on Xeon E3-1240L v3 2.00GHz. Down to 800 to 1500 MHz at low load. Was up to 2800 and never below 2000 MHz before with same load.

Beta 13 is out now with my intel-pstate driver patch integrated. 

Does this mean we need to leave the intel_pstate=disable in the syslinux.cfg?

 

With that edit left in the syslinux.cfg I see three cores stepping right down to idle and one hovering above idle. If I take that line out of syslinux.cfg and reboot b13, all four cores run at almost full speed but can be seen altering speeds to around 95-100% of full.

 

EDIT : I can see them dipping down to near idle very briefly then zipping back up to full again. The server is currently idle with all drives spun down. CPU load seems to be hovering at about 1% but all four cores spend most of their time within a few % of 100% speed.

Does this mean we need to leave the intel_pstate=disable in the syslinux.cfg?

 

With that edit left in the syslinux.cfg I see three cores stepping right down to idle and one hovering above idle. If I take that line out of syslinux.cfg and reboot b13, all four cores run at almost full speed but can be seen altering speeds to around 95-100% of full.

 

EDIT : I can see them dipping down to near idle very briefly then zipping back up to full again. The server is currently idle with all drives spun down. CPU load seems to be hovering at about 1% but all four cores spend most of their time within a few % of 100% speed.

 

You wont need the

intel_pstate=disable

in syslinux.cfg any longer.  Are you seeing the high frequencies without 'intel_pstate=disable' on your i3-4160 cpu?

The behavior is different. It scales down but for short periods and quickly jumps to the max. frequency on all cores.

 

I have "Intel® Core™ i3-4130T CPU @ 2.90GHz"

 

Yes I am seeing high frequencies on all four cores when the b13 server is idle without the intel_pstate parameter but the values change frequently as I watch which is certainly new behaviour.

 

I do occasionally see them dip down on one or two cores to about half but never as low as it went with the b12 edit. It tends to hover around 3575 on all 4 cores with the occasional dip to 3400 and the very rare dip down to around 2200 for a moment. The CPU utilisation varies between 1% and 6% so there seems to be some tasks going on.

 

I wondered if the act of observing the UI holds the frequencies up?

Coming into the room when it was quiet this morning I was more aware of the noise of the Intel CPU fan when compared to when I was using the pstate disable parameter. I would say the CPU frequencies, while fluctuating, are being held high.

 

I cannot easily provide CPU temperatures or fan speeds as I am running the server headless but if there is a way through the unRAID UI or putty to provide any information, let me know.

The behavior is different. It scales down but for short periods and quickly jumps to the max. frequency on all cores.

 

I have "Intel® Core™ i3-4130T CPU @ 2.90GHz"

 

I am having the same behavior, it seems to be cycling. It's better then it was in b12 (prior to editing syslinux) but it's not as good as the fix editing syslinux.

Running b13, most of my cores are throttled, but one (any one - it keeps changing) always stays at maximum speed.

 

My CPU is :  Intel® Xeon® CPU E3-1230 V2 @ 3.30GHz

 

Dashboard shows the CPU load as 1 or 2%.  Seven cores are always reported as 1600MHz, but one is always reported as 3301MHz.

I think the problem is just confined to the Haswell processors, not Ivy Bridge Xeons.

 

I have put the intel_pstate=disable back into my syslinux.cfg until we can see if there is a better solution.

Yeah, it's only Haswell I was having the problem with.  Sandy and Ivy are fine.

 

It's not just a reporting issue, I can see the power consumption on my Kill-A-Watt.  With Haswell the machine it's sitting at 35W, which means it's running the CPU hard.  That machine under the same config with Windows idles at 22W.

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?