Performance Issue in Driver due to Processor C state wakeup delay

Hi,

I am facing an issue related to low Transmit performance on PCIE WLAN driver for 11 ac device on a modern standby capable laptop with intel i core 3 and 8 GB ram.

issue is that the transmit performance is degraded by almost 20 pcnt …after analysis with xperf -on power traces
it is observed that the processor is in c3 state bulk of the time … as a result it increases the time between the interrupt raised and received by driver.
if i open any application then the throughput increases …and its observed that during this time the processor is in C1
so it seems if just the WLAN traffic is ongoing the processor is in c3 state most of the time

is there any way from driver i can stop the c3 transition or is there any suggestion to better schedule threads or DPC to avoid c state delay?

thanks in advance

its in WIN10 os

The processor should only be in C3 if there’s nothing much going on, and if there’s nothing much going on, why is WLAN performance an issue?

The Core i3 is the bottom end of Intel’s Core line. It’s not intended to be a hot performer.

Hi Tim,

thanks for your reply , i am really sorry that i was not able to present the case clearly

to answer your question
The processor should only be in C3 if there’s nothing much going on, and if there’s nothing much going on, why is WLAN performance an issue?

Although the throughput test is ongoing network activity over wlan adapter in the range of around 250 Mbps.
but still the processor move to idle state (C3)
this test is being performed to measure WLAN throughput using standard tool like chariot or iperf which is failing and not able to reach its optimum by almost 20 pcnt .

The intention is to make the WLAN transmit throughput reach its peak by making the processor run in active mode during the throughput test …

this issue (interrupt delayed due to c state transition) is also observed in i5 processors …

Thanks
Joyjit

Well… the only way I know to do this is changing the Power Plan.

I’d also be curious if calling if WdfDeviceStopIdle makes any difference… purely as a side-effect.

Peter

if i open any application then the throughput increases …and its observed that during this time the processor is in C1

Don’t you have some usermode program in the test setup, like iperf? What sort of apps cause exit from C3 ?

– pa

Hi Pavel,

its observed that application with GUI not console based will prevent the C3 transition

iperf is command line …and while chariot is used only endpoint is installed on the DUT laptop which is a service runs in background.

so both the cases there is no GUI.

also i have observed that if from device manager simply perform scan for new hardware the processor in active state

if some applications can prevent the C3 transition does it mean the applications can control the processor transition by some API?

Thanks
Joyjit

Again, from a user mode app you can change the power plan so that the processor never enters C3.

Did you not see my reply earlier?

Peter

Hi Peter,

yes i see there are APIs like ReadProcessorPwrScheme and WriteProcessorPwrScheme which as per the documentation in msdn seems they can change the power plan of processor run time… is there any kernel version of these API then i can call them from my driver

Thanks
Joyjit

is there any kernel version of these API then i can call them from my driver

None that are documented, as far as I know.

Peter

if from device manager simply perform scan for new hardware the processor in active state

Well, the processor is in an active state any time there is meaningful work to do. The processor changes C states potentially thousands of times a second.

this seems like behaviour by design

I have had similar issues with USB 3 device drivers. As i recall, the USB host was generating Missed Service Errors on Isoch out transfers even though the transfers were submitted with plenty of time. The root cause was increase in PCIe response latency caused by the processor entering a lower power state. The host wasn’t able to read the data from system memory before the microframe ended do to the increase in PCIe latency. Normally PCIe latency is very small, well under 10 microseconds. When the latency gets up above 50us, it gets hard to transfer a lot of data in a 128us microframe.

You may be able to get some info out of the system on average and max PCIe request latency.

This was several years ago and I haven’t tested on recent intel CPUs.

Eric

1 Like