C-idle state

Hi,

we have a low latency, high channel count kernel audio streaming driver which operates on user-kernel space shared ringbuffers. It clocks its user space ASIO client .dll from an IRQ signalling DPC via a shared user space event. So the actual continuous streaming is IOCTL-less.

While streaming on some of our test machines we see a significant DPC latency increase (0.7ms!) when the CPU enters its C-idle state.

Now, I am investigating how to inform Windows that the driver is not idling. From the amount of IRQ signalling DPCs I would assume its pretty clear that there is something heavy going on, but anyways. The closest I found seems to be the “Component-Level Performance State Management”. However the msdn is unclear (at least to me) if this is just a feature which informs the drivers so it can organize performance states of its devices or if it by itself controls the system performances states (and as a consequence can prevent the CPU from falling into C-idle).

Would you please share some inside!

Thanks and Cheers,
Hagen.

> Would you please share some inside!

PoFx F-States and Perf States are designed to be ways for the driver to notify the PEP about the device’s needed power and performance, so the PEP can coordinate the bus power and processor’s performance states. Think of it as a way for a Function Driver to have an express connection with the PEP and the BIOS, without involving the Bus Driver or anybody else in the dev node.

Now… having SAID that… This is a very new set of interfaces (F-states have been around since Windows 8… Perf states arrived in Windows 10). I’m not sure if you can use this facility to have the processor avoid entering a C-State. You might try querying the performance info set from the PEP to see what it tells you.

I’m particularly interested in this area, and I’ll be interested to see what you turn up. If you don’t find more info, I can try to make some enquiries or do some digging as well.

Peter
OSR
@OSRDrivers

Thanks, Peter, for your “inside”!

I would approach Microsoft thru the means of MSDN subscriber support. If you have a more direct way of getting those information it would be highly appreciated if you are willing to utiilize this!

I am still uncertain how to address the issue; as a temporary workaround the user mode ASIO driver .dll disables C-idle states via PowrProf.lib before starting streaming and resets its value on stop.

However this approach is not suitable for our port class audio driver.

Thanks & cheers,
Hagen.

I spent a couple of hours this morning trying to suss this out myself. But, I’m sorry to admit, I’ve only succeeded in getting myself more confused.

So… I’ve sent-off a query to a good buddy who’s worked in this area… I’ll let you know if I learn anything useful.

Peter
OSR
@OSRDrivers

Thanks Peter, that is all really appreciated!
I am also looking into the “Component-Level Performance State Management”. I will update here on any findings.

Thanks & cheers,
Hagen.

Is it correct to assume that you presently DO NOT have any PoFx integration in your driver?

You don’t set your WDF_POWER_POLICY_IDLE_SETTINGS IdleTimeoutType to “SystemManagedIdleTimeout”, right?

I’m just trying to eliminate the simple stuff,

Peter
OSR
@OSRDrivers

Thanks, Peter,
correct. I currently don’t have any PoFx integration, as I need to understand what and more how it actually works.

Thanks & cheers,
Hagen.

Just to follow-up: I did NOT drop this. I asked my friend, who put me in touch with the right devs… who then proceeded to tell me absolutely nothing.

I don’t know why. I think this is a good and valuable question.

I haven’t given up hope but…

Peter
OSR
@OSRDrivers

This is a good question, would like to see any update too. IIRC someone complained in this list about C states affecting his PCI serial controller…

– pa

On Sun, Feb 11, 2018 at 1:28 PM, xxxxx@fastmail.fm
wrote:
> This is a good question, would like to see any update too. IIRC someone complained in this list about C states affecting his PCI serial controller…
>

Very interested in the issue for this reason, so thank you for
following up on this Peter.

Cheers,
R0b0t1