I am talking about 802.11AC (866Mbps) on ATOM based CPU,
Slow CPU on high rates will cause CPU utilization issues.
Thanks for your help
I will try the techniques above
>Does your driver spend excessive time in DPC or in ISR? - spending most of the
time in DPC
Have you profiled it to find bottlenecks? no, can you explain how?
Install and run Microsoft XPERF tool.
As a quick and dirty profiler, get your SUT into this high consumption scenario and break into debugger. Save stack traces on all processors (0k;1k;2k;3k). Do that a few times to get a rough understanding where are they spending time.
Does your DPC have to spin on polling any HW bit?
Also, to see if there is a pathological spinlock scenario, run your SUT in single processor mode, see what CPU consumption you’ll get. In some test scenarios the tuple lookup code will have too much contention for the table spinlock (which Microsoft needs to convert to read-write lock).
Have your DPC only pick the completed packets, and queue a workitem to actually indicate the RX data to NDIS.
Fyi, In win8 , xperf became WPT
d
Bent from my phone
From: xxxxx@broadcom.commailto:xxxxx
Sent: ?12/?9/?2013 7:38 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] NdisGetCurrentProcessorCpuUsage doesn’t change
>Does your driver spend excessive time in DPC or in ISR? - spending most of the
time in DPC
>Have you profiled it to find bottlenecks? no, can you explain how?
Install and run Microsoft XPERF tool.
As a quick and dirty profiler, get your SUT into this high consumption scenario and break into debugger. Save stack traces on all processors (0k;1k;2k;3k). Do that a few times to get a rough understanding where are they spending time.
Does your DPC have to spin on polling any HW bit?
Also, to see if there is a pathological spinlock scenario, run your SUT in single processor mode, see what CPU consumption you’ll get. In some test scenarios the tuple lookup code will have too much contention for the table spinlock (which Microsoft needs to convert to read-write lock).
Have your DPC only pick the completed packets, and queue a workitem to actually indicate the RX data to NDIS.
—
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>