Hi Hlidskjalf,
Here is the latest update about the issue. For Panther Point chipsets + Lewisville (82579) architecture, Management Engine/AMT accesses the network hardware every 4-5 seconds, even when the operating system is up and running. When the FW performs read/write operations from/to HW, network driver is not allowed to access the HW simultaneously, because it could cause the HW queues to be corrupted. To avoid it, when the network driver wants to send or receive some data from network, it checks if the ME FW is currently accessing the HW. If it does, driver needs to wait for ME FW to finish its HW accesses. During this time, network driver is not allowed to perform any HW operation.
To accomplish the waiting for ME FW in driver 12.10.28.0 and earlier (release 19.1 and earlier), we implemented the wait mechanism in the driver using Microsoft’s function called NdisStallExecution(). However we had a few reports against driver 12.10.28.0 from customers who reported very high DPC latencies (~120 ms) and audio glitches during streaming audio/video applications (like watching video from YouTube). We investigated this issue and we found out that during waiting time NdisStallExecution function basically blocks all threads executed on current processor. It means that our waiting was causing delays of applications running on
the same processor's core - when the Youtube video was playing on the same core, customers saw glitches.
Because of that, we implemented different waiting mechanism in driver 12.10.29.0 (19.3 release) - we still wait for ME FW, but wait mechanism
is implemented in different way and is not using function provided by Microsoft. This solution let us resolve the audio glitches problem - when we wait for ME FW, the processor can still switch the contextbetween different threads to play the music or video. However this solution has a small side-effect: in specific configurations, it causes DPC latencies (~5-6 ms), even if latencies have not been observed with earlier driver. However Microsoft doesn't provide any other "wait"
mechanism for network driver and implementation we did in driver 12.10.29.0 is the best solution in Microsoft opinion. This allowed us to achieve 5-6 ms of DPC delays comparing to 120 ms of DPC delays when we used NdisStallExecution and there was an audio stream on the same core.
The main problem in this issue is ME FW accessing the hardware every 5 seconds and blocking it. From the network driver perspective, there is
no good mechanism for dealing with such big delays. We talked to Microsoft about this and the only solution they proposed us was mechanism we already implemented. The best solution we have for customers dealing with this issue is disabling ME FW / AMT if it's not needed and if disabling it is possible
on specific platform. If the ME FW is needed, we created a registry key in driver 12.10.29.0 to configure the waiting function. This key can be found in HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE -BFC1-08002bE10318}\device_number, when device number means the number assigned by Windows to Intel Network Adapter. The key name is "AlternateSemaphoreDelay" and its default value is 50, which means that time is measured by executing 50 times certain loop. Decreasing this value can possibly decrease DPC latency, depending on processor speed and load. However if the system is highly loaded,
even the very small values can result in high latencies. Setting this value to 0 enables the NdisStallExecution mechanism implemented in driver 12.10.28.0. Since there is a few other fixes in driver 12.10.29.0, we recommend you to set this value to zero instead of downgrading to 12.10.28.0.
Assuming, we recommend you the one of the following solution (starting from the best one):
1.) Disabling ME FW /AMT if it's not needed
2.) Doing some experiments and decreasing AlternateSemaphoreDelay value to achieve smaller delays
3.) Setting AlternateSemaphoreDelay to 0 to enable the older wait mechanism from driver 12.10.28.0
Hope the above helps.
rgds,
wb