i had posted this on the cakewalk forum fter being challenged about Turbo boost not being a good thing. thought i would share it here as well.

to fully grasp this you really need to understand what ACPI is and to know that Vista was the first to "force" compliance and Win 7 has further enhanced
ACPI. While not new (97/98?) it was a long time in being implemented fully.
some of you remember being able to change/assign IRQ's. This ability disappeared with XP (software level) and with APIC motherboards (HAL) along the same time frame.
during that transition people were warned to NOT install the OS in "Standard computer mode" long gone is that option now. (XP SP1 it was gone)
This was the beginning of ACPI.
http://www.acpi.info/DOWNLOADS/ACPIspec40.pdf
warning very heavy reading. in i nut shell the beginning of "green" power management for computing.


All of the "power saving modes are intertwined but do function separately to a point.

Speedstep/ (EIST) was introduced i think with Pentium 4 desktop processors but more commonly became an issue with Laptops. (actually Pentium III mobile)
It was not uncommon to have a 2GHz Laptop and find it running at 700MHz. this is still a part of the issues with a laptops and most bios wont allow for
it to be turned off.
Thats why this guys software became very popular.
SpeedswitchXP

the time it took to go from 700MHz back to 2.0GHz was way too long and caused drop outs etc with audio.

some quotes taken from here: Processors — Frequently asked questions

" the processor is able to reduce periods of system unavailability (which occur during frequency change)."
" Clock Partitioning and Recovery" " The core clock is also able to restart far more quickly under Enhanced Intel SpeedStep Technology"
" Because Enhanced Intel SpeedStep® Technology reduces the latency associated with changing the voltage/frequency pair (referred to as P-state),"

System unavailability? why would i want this on my system?
Recovery? Restart? Latency? sounds like what my wife goes thru trying to get me up in the morning for Church on Sunday.
all of this will cause issues for audio

EIST(desktop) dynamically increase/decrease its clock speed between its minimum clock and its normal operating frequency, as well as voltage, in order to optimize for power consumption.
in other words a performance reduction while using the system, the system may feel you don't need full power. drats just heard a drop out.

C1E Halt: while similar reduces Clock speed by adjusting the multiplier (Core clock to system bus ratio) and to some degree VID. (voltage) this is a more common occurrence with light use
or on today case of Multicore shutting down a core or 2.

C3, C6. This is a deeper sleep with a complete core(s) shut down (Gate off) and no voltage/Data at all. harder to recover from quickly, previous data is cached elsewhere and needs to be re-cached in L3 memory
to re initialize full muliticore, multithread use. Part of Core parking
http://download.intel.com/design/pro...=tech_tb+paper

Turbo boost: this is for those who like pictures http://download.intel.com/products/p...ei7/319724.pdf
and here with more pretty pictures AnandTech: Intel's Core i7 870 & i5 750, Lynnfield: Harder, Better, Faster Stronger

Turbo boost looks like a great thing and it is for many applications. Bear in mind 1366 Processors' cant Turbo up past stated speed with all 4 core active like the 1156 can.
However its really moot. The issue with Turbo is while it may be clocking up 1 or 2 cores it can also set 1-2 cores into C3, C6 state.
Its that time it takes to go from C3, C6 to active when running at low latency heavy project that will be trouble.

Core parking: since this so far only seems a potential (not definitive) issue for Sonar i wont say much. (its also only for Sonar) its Hyper-threading way of doing C1E if there are not enough threads
required it will "park" shut down the HT cores to a ready but not active state. (Win 7 only). Core parking is supposed to be an efficient way of data caching with concern to HT as well. With Core parking enabled it can cause threading issues in Sonar.

All of this power management is supposed to be about "Green" frankly if i want to save energy i will lower my heat and put a sweater on.
for DAWs ideally you would turn all of this off and have 100% access to full power at all times. leaving it on can cause issues particularly low latency power users.

as Turbo kicks in its raising the BCLK (base clock) or what we called the FSB as you raise the FSB it also increased the Memory speed. While this may seem good it can also push the system memory over the limit.
some of you may not be seeing issues if using DDR3 1066 or 1333 as this ram has some upper limit room, particularly if not a low CL setting.

if using DDR3 1600 (and its actually running @ 1600) and turbo clocks up say up to 145 from 133 base clock you ram is now @ 1680 which can fail at that speed depending on what ram you have.
all our systems have all power saving management off so we can redlilne the systems.
in other words all systems have a QPI of 6.4 and DDR3 1600 @ 1600.

The other thing i have concern for is how well (fast) the crystal clock (real system timer) is adjusting for this.
Audio is the only software i know of that is working at near real system time and as you lower buffer settings you get closer to it. modulations in the system timer (even slight) could create
system stability issues but now i am getting way out there. :-)

I asked one of my support guys to write a why there is issues with Turbo etc.

Scott
ADK

The issues showing back here when Turbo Mode is active are random drop outs at lower latency and also plugins causing drop outs. Firewire Devices seem to be far more interrupted by the Turbo State changes. The issues are intermittent due to how Turbo Mode doesn't always change the Base Clock Frequency which alters the Ram frequency and it doesn’t always turn off cores. Sometimes it is fine frequency adjustments that raises the clock speed less than 100 MHz which also raises the ram speed. If you launch CPUID you can watch this activity real time. What is for certain is the C- State or Frequency changes happen via Communication to the ACPI which is on the SMBus and Bios. This communication is on the PCI Bus and at a very high Priority. Since audio requires constant CPU communication at a high priority especially at lower latency this will cause interrupts in the audio especially at lower latency or when plugins have some delay compensation affecting the audio.

The Turbo Mode will also gate off cores based on what the Host is sending for threads which was the real purpose for Turbo Mode. This works great with video games and Business applications. However for audio it's a nightmare. Remember your audio host program might multi-thread great but that doesn’t mean your plugins do. Plugins and Plugin cards often only single thread which will send high priority commands to one or 2 cores. All of the Turbo Mode moderation is at the CPU. If the CPU determines that the data is only single threaded it's going to start shutting down cores for performance sake. When this happens cache may be wiped which is part of the C state process which can cause current audio data that other cores were using to be wiped out. This process forces the CPU to restart the thread from the beginning which will show up as an audio drop out since audio requires the stream to be constant. Hence why this shows up intermittently and is much more common at low latency.

Remember all of this communication is traveling along the PCI Bus taking high priority. Other Devices requesting CPU time are pushed to cache state while this is going on. Also this communication is taking bandwidth that PCI bus devices are using. This really shows up on Firewire Audio devices due to how those are designed and laptops due to resource stacking and Device ID prioritizing to squeeze as much data through a limited highway as possible.

Once again all of this is intermittent due to what you are doing, what hardware/plugins you are using, and what latency you are running. You might be fine for 1 session and then have nightmares while mixing. Leaving Turbo Mode active is putting allot of possible failure points into your workflow and will cause issues that may seem like they are due to other factors but are really due to the C state changes and the PCI Bus activity that is occurring from the Turbo Mode and EIST.

There is allot more to what is going on in the Background on the current hardware besides this due to the architecture that will also exacerbate this issue more but that is a much longer discussion.
Eric

Dovetails the current Mac Pro/Nehelem discussion nicely, thanks for sharing!

Exactly the issue on Apple.
the difference is we can turn it off in Windows

obviously the point of the post was why you should turn it off.heh

Scott
ADK

There are ways (workarounds!) to turn off CPU Speedstep features in OS X. The simplest is to create artificial load, but that also creates heat (run "CPU Load" at 9 or 10 with the demo version of Coolbook).

Another option for the less faint at heart is to remove the kext that is responsible for handling CPU powersaving. This will leave the CPU at its lowest clock-rate, but using the full version of Coolbook then allows you to set the clock-rate manually (or let Coolbook handle it automatically).

I don't know how good the latter works for Core parking though and if Coolbook support the latest CPUs at all. Guess someone has to try out for us.

Timur,

Coolbook does not work on any of the Xeon Systems, I am sure we have covered this in past discussions.

EIST / C States are not arbitrated by OSX/EFI anywhere near as well as Windows/ BIOS - I know I am starting to sound like a broken record with this , sorry, but there is more to it than a simple kext .

We have been all over the modified kexts on the test MACPro rig for quite a while, and it does not resolve the clocking issues , partly due to the C states being inaccessible.

No problem with you refreshing my memories! I remember about the Xeon information, but we are not (only) talking about Xeons here, are we? What I wanted to express was just that there are possible solutions to the C states problems. So it's not like the world has to live with it.

Besides, on Windows the problem also persists and unfortunately I did not find a single third party application that would reliably turn off Speedstep by 100% on my bootcamped Macbook Pro. Most of these applications ain't updated anymore and CrystalCPUID *is* able to switch clock-rate, but only for a split-second before it turns back to automatic switching again. Rightmark CPU Clock utility has some extended C-States options that influence the CPU, but doesn't get a real grip neither.

One good thing about Windows is that on XP using the "Always On" profile switches off dynamic clock-rates for many CPUs and on Vista/W7 using the "Performance" profile at least makes the CPU clock ramp up towrds maximum alot earlier and easier. The latter also turns off PCIe bus power-saving features which in their maximum state ("Power Saving" profile) have a very reproduable influence on audio performance (including Firewire interfaces since the FW port is connected via PCIe bus as well).

It's even more complex with some older mainboard/northbridge chipsets. NVidia used to have alot of trouble with some states where the CPU is disconnected from the northbridge and needs to be reconnected. That being said, I had a wonderfully stable and good performance NForce4 audio desktop.

About the simple kext solution: Removing the kext removes OS X control over the CPU. So anything that is "bad" about OS X solution is removed with it. But there are two problems remaining:

1) Since removing the kext leads to the CPU being fixed at its *lowest* frequency you need a way to push it up to its maximum. On my Core2Duo I can do it via Coolbook.

2) In my tests running the CPU with artificial load still seemed to lead to *slightly* better results. But both workarounds lead to audio playback being possible at low and high load where before you would run into buffer dropouts.

Just to mention it:

Different applications behave different. Ableton Live is more prone to the problem than Logic 8 and Reaper will likely behave all different as well, since it has its very own unique and user managable thread managment.

So my advice would be to collect experiences with different applications before going into labor with kext modifications and whatnot. Also try out how artificial CPU load works out (Coolbook should be able to do that on any CPU).

just wanted to point a few things out...

the nehalem speed step power saving feature can be turned off entirely in a decently specced motherboard for p.c. users leaving the turbo function intact. turbo is a combination of the p-state function and the manipulation of the multiplier. it has nothing to do with speed-step. speed-step is to lower power when the cores aren't active enough to warrant running them all full throttle which is necessary due to the hi-k metal gate process they are made on and the clock speeds they ship at. the process means less leakage, less leakage means more trapped heat in the switching logic gates where the hi-k metal is used. there are more benefits than negatives to using hi-k metal gates such as reduced state change time so the decision to go for the newer process was used. the issue is that intel saw the problem first in the core2 quads when they were overclocked. 1-2 cores used at a certain overclock would be fine but when extra threads were created the stability would go out the window. and intel was planning on improving single threaded apps with an auto-overclock function with nehalem.

enter turbo and the c6 p-state. turbo is to improve single threaded performance. c6 is to save batteries in laptops. c6 will completely kill power to a core shutting it off with 0 leakage. c1 and c3 will reduce power when the core is downclocked. c6 takes advantage of the hi-k metal gates and can switch the cpu to a zero state in under 5 clock cycles and wake it in under 12. c1 and c3 just change the voltage along with the internal cpu bclk being slowed for variable power saving. this is the issue your having, you have c1e and c3 power states set to enabled at the hardware level. turn them off and turn on c6 only and leave turbo on.

also turbo does not raise the bclk, it raises the multiplier directly, blck stays the same. that's why you have to be careful when overclocking and checking your results for stability as the turbo will cause glitching if you are too close to the thermal envelope's upper limit.

great info

W-W,
Turbo needs to be off as does ALL of the listed states.
anything less can casue issues.

by turning off C1e turbo cant shut down cores. shutting cores down is part of Turbo.
Turbo for Audio/video is not wise

Scott
ADK

I would not subscribe to the latter in all cases. NI Kore does not offer multicore support when used as standalone, for instance. Pushing one core while turning off others could be quite helpful for such an application.

and at the cost of?? higher DPC for 1. did you not read what issues are coming from the Turbo boost?

Scott
ADK

As long as the offline cores stay offline there should not be any much of a problem. And I don't know about you, but when I'm using Kore then the rest of my computer's load is very much under control (unless you start reading emails on stage).

This doesn't mean that I don't see the problems of Turbo, but I also see the benefits. There still is alot of single-core software out there and frankly most audio applications don't exactly "shine bright" when it comes to their multicore implementations anyway. So sometimes it can be better to run your audio software on one core at higher clock-rate even when theoretically it should work with several cores.

Very informative thread, thanks to all who appreciated.

I messed around with this this morning, and my dpc meter was definitely moving around quite a bit at low latencies with c states enabled (256 buffer at 24/96, over firewire), I did not experience any dropouts with playback, but I imagine i might have if i were recording under those circumstances.

With C states off my dpc meter was as placid as can be.

One thing that worried me though: these features decrease heat output, if i leave them turned off, will stock cooling at stock speeds be sufficient? my case isn't exactly well ventilated, (corei7 860 in an antec sonata,)

I know the 1156 and 1366 chips have a high heat tolerance, I think ill try to run it at load for a bit tonight and see if it gets toasty.

--Mikey

Edit:

this is my system, for the sake of context:

Cubase Studio 5.1.1 32bit.--Windows 7 Professional 64bit.--i7 860 lynnfield 2.8ghz.--Gigabyte GA-p55a-ud3 Motherboard.--8gb Corsair xms3 ddr3 1333--Sapphire Radeon 4670--SIIG pci firewire bus/TI chipset.--TC Electronics Konnekt 8; Software Package 2.4.06252, Control Panel 2.3.1 r2924, Firewire Driver 3.5.0.7171

Mac Pro Audio Update 1.0

What exactly is the update addressing ?

It says it reduces processor utilization , which will probably have something to do with the heat/load anomaly reported in the other thread, whether that involves improvements in the arbitration of EIST/C States that will benefit DAW's is the big question.

no need to worry about heat.

Scott
ADK

I hope you set it up this way on my pending new laptop thumbsup

Good information, thanks.

Greg

c1e is not to shut the cores down, it's to lessen their power state. c6 is the shut off. and turbo works just fine with c1e and c3 off. it simply clocks the other cores down without reducing the power flow or shutting them off completely with c6. c1e and c3 are simply not useful at all for a desktop unless you're a large enterprise and worried about the power bill from 1,000's of desktops sitting idle eating more power than they need. it was designed for laptops and corporations where even some power savings helps the bottom line. c6 is for shutting off unsued cores entirely with no power draw at all, not powering them down to a low power state and still being able to be used.

turbo works by altering the multiplier for the cores individually. it will raise the needed workload cores and lower the others. the c1e and c3 power states assist with power savings at these reduced clock rates and can reduce the cores operating speed further by also manipulating the internal power save lowered multiplier of speedstep. but aren't inclusive to how turbo works. speedstep can be disabled without affecting turbo mode if your motherboard has the hooks in the bios to do so.

wrong.
C1e off means turbo can NOT turn cores off.
C1e is a halt state (off but cache not flushed) C3,6 are deeper sleep gate off cache flushed) with any of these off turbo can only change the mulitplier or FSB.
and again any use of these "power saving" modes can result in issues.

there is absolutely NO POINT to having any of it on. Turbo on a 1366 cant clock up without turning cores off so end of story there
Turbo on 1156 can actually clock up all 4 cores 1 notch but will also increase in increaments causing ram speed to rise, bam issues again.


Scott
ADK

HI Greg,
yes we had to get yet another new bios for the laptops asking for all these wonderful power saving modes to be turned off.
its really bad on laptops conpared to desktops.
(really big DPC spikes)

Scott

C1E is just HALT or MWAIT(C1) instr in pipeline with a vid ramp to the lowest p-state. There's no cache scaling or flushing. Why would you WBIVD after a C1? Cores can do C1/C1E individually and not having C1E does not prevent the package from engaging TB.
C3 dumps the L1 and L2 to the L3 in uncore and turns off the clocks.
C6 saves the register state to SRAM and turns everything off.
There is no FSB in Core iX. Everything is multiplier changes.

Generally its the OS or BIOS' fault for audio glitches as the _CST recovery times aren't tuned for a worst case scenario like this. The powermgmt scheduler given good information should be able to make a good call as to when it actually use c-states or engage TB.

I saw this post and I thought is was real interesting. I recently build a computer with a i7 920 . I am overclocked to about 3.5. It is pretty amazing what you can do. I have noticed a few quirky things. I have been using pro tools 8.0.3. What is does it is freezes, but not a normal freeze but a slow freeze, and then one of the threads will be at 100%. It does this with sessions loaded 20% occasionally.

This issue also occured at stock speeds as well. I have been trying to figure out what has been causing the problem. But it only occasionally. It also seeming to freeze when I was using Flux:: sound and picture development plugins. (The free ones.) I have been trying to figure what is causing the random freezes. I know pro tools is still in the beta stages for windows 7. I am going try to disable turbo and see if this fixes the problem.

I have heard that having a 21x multiplier vs 20x multiplier increase system stability.

Better stability from lower multiplier higher bclk? - Overclock.net - Overclocking.net

Tested with prime 95: 16+ hours.

Is this an issue with voltage on manual settings or on auto/both?

you basically just repeated what i said. and FSB=Bclk

I didn't repeat you. You were wrong about C1E and a relation to TB. I clarified C3. And there is no FSB scaling.

FSB != BCLK. Integrating the northbridge means there is no FSB.

now you are going to argue symantics?
FSB/BCLK same dang thing. are you going to spell check me next?

if you turn off C1e Turbo can NOT shut down cores. how do you see i am wrong.
and if you read the original post i had already clarified C states

so you think leaving turbo on is a good thing?
Scott
ADK

The people in Sunnyvale, California at 1 AMD place are wiping their brows and saying "Phew".... Ha!

great thread Scott.

> there is absolutely NO POINT to having any of it on. Turbo on a 1366 cant clock up without turning cores off so end of story there
Turbo on 1156 can actually clock up all 4 cores 1 notch but will also increase in increaments causing ram speed to rise, bam issues again.

Just plain wrong. Turbo on a 1366 certainly CAN increase multiplier (or "clock up"), without turning off cores. This is down to how mainboard manufacturers implement the setting and there are Intel RECOMMENDATIONS. Plenty of boards can have turbo enabled without losing cores.

On a UD5, you can select a permanent 21X multiplier on an i7 920, and this is done by permanently having Turbo mode active. Again, no cores shut down, full load possible on all cores, all cores working at 21X etc. etc....


> as Turbo kicks in its raising the BCLK (base clock) or what we called the FSB as you raise the FSB it also increased the Memory speed. While this may seem good it can also push the system memory over the limit.

Again, just horribly wrong. Turbo increases multiplier, NOT bclk over standard settings. Memory DOESN'T suddenly run 10% (or whatever) above rated speed just because turbo is active.


> The other thing i have concern for is how well (fast) the crystal clock (real system timer) is adjusting for this.

The real-time-system timer is NOT dependant AT ALL on BCLK or multipler.


> Remember all of this communication is traveling along the PCI Bus taking high priority.

CPU/RAM are connected via the PCI bus on i7s in 2010? First I heard of it.

this is getting old. and no time for a lenghty answer.

yes you can force the mulitplier up 1 we do this or overclock to higher whoo hoo.
we also force QPI to 6.4 whoo hoo.

a picture is worth a 1000 words.
everything off
http://www.adkproaudio.com/images/dpc2.jpg

just turbo on
http://www.adkproaudio.com/images/dpc1.jpg

all c states on with turbo
http://www.adkproaudio.com/images/dpc3.jpg

so the obvious choice is All C states AND TURBO OFF
which is the point of this thread.

i dont have time to fool with laptops today as it would require flashing back to an old bios then back to new
the issue is way worse and yes on the i5 laptops the memory IS most certainly changing with the BCLK.

Scott
ADK

Just a quick one , and I'll let you boys continue with your little overclocking bout.. :-)

The capability of the added multiplier on the latest BIOS's is not dependent on Turbo Boost at all , you can simply set the clock permanently one step up from the standard clock speed even with Turbo Boost and all C States and EIST disabled.

Carry on..

Great post! Just today I found the disturbing setting for the noisy crackly Firewire interface connection - strange that the C1E setting in AsRock BIOS speak is not under the "CPU", but under the "Chipset" tab!? And I think that many manufacturers have a different terminology. Don't ask me how I long it took me to find that out!

Briefly: if you want reliable operation, switch all this stuff to DISABLE! :)