Manuel wrote:Thanks Tmur, I forgot to explicitly mention that say it's a desktop I am referring to, so there's no Battery device under in the Device Manager. I am using a custom high performance power plan with every power-saving option turned off, including core parking. Changing buffer size does affect the look of the CPU usage graph consistently but only marginally: the spikes are still there and occur at the same frequency.
Since you already know how to mess with power-plans, here is something to try out:
Turn "Processor Idle Disable" to "Disable Idle". This will run your fans hot, but makes sure that CPU power-management is really completely disabled (all cores will run at maximum frequency, no C-states, no nothing). Also make sure again that "PCI Express -> Link State Power Management" is set to OFF. Last but not least it may be worth a try to turn off Link State Power Management for HDs, too (should not, but who knows).
You may have to use a software called "Throttlestop" to specifically turn off C1E states with your own power-profile, because I don't think you can turn C1 off unless you use the "Disable Idle" option (which heats your room as well).
If you are using the special power-profile that is provided by Presonus, then turning "Disable Idle" is exactly what it does anyway. At least when I downloaded it more than a year ago and checked it (could have changed in order to keep some computers from burning the house :-P).
Changing the bandwidth has the greatest impact on the CPU usage graph: Reducing the bandwidth (e.g. selecltl "Analog") results in taller and clearner spikes, increasing the bandwidth (e.g. All channels) decreases spike height but the graph looks "noisier".
If reducing the bandwidth of Firewire has such an effect then it is another indication that Firewire may be the cause.
Timur: Do you get any sort of specific and consistent CPU activity on any one particular core that only happens when DIGICheck or any ASIO client is running? If using DIGICheck for this test, please ensure that audio processing is enabled.
I will test this once I find time. But I already tested the CPU behaviour of the various Windows Firewire drivers some time ago, and indeed, the Windows 7 non legacy driver can cause spikes on one CPU core. Actually both the W7 legacy and W8 non legacy driver do that, too, but these are considerably smaller (=lower average CPU load). In practice it doesn't matter much, though, because other CPU control mechanisms even them all out (average temp and wattage allowed, especially since I am using a laptop/MBP).
The reason why you are seeing spikes on only a single core is simple: Interrupts/DPCs can be handled by every single core separately. So whatever driver (likely FW) is causing the spikes, it will only be handled by a single core. And Windows likes to keep these things consistent if possible (stay on the same core for the same task).
Since DPC latency checker is no of help because of this, you can try LatencyMon (not sure) or Windows own Performance Monitor. With the latter you just have to add "Processor -> All instances" and then switch to the text view (not graphs). This will show you C-states (idle states), interrupts and DPCs usage for every single (logical) core.
Anyone: Does it matter if the Firewire card is PCI or PCIe?
It can matter when your PCI bus is connected to PCIe via a bridge chip instead of a direct connection to the (Southbridge) chipset. Some of these bridges cause lags, which could result in your behavior (CPU core waiting for a response that is not coming in time).
