10th February 2010
#1
Lives for gear
Thread Starter
C1E, C3, C6, EIST, Speedstep, Turbo Boost, Core parking
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
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
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. 
