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 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 …
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
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.
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.