intel nic drivers 19.3 huge 6000+ dpc latency spike once a few secs

[ATay3]

hi, i would like to report that the new intel nic drivers version 19.3 that just released recently has huge 6000+ dpc latency spike once in a few secs.

my specs

Intel(R) 82579LM Gigabit Network Connection

windows 7 SP1 32bit + lastest windows update

i downgrade to intel nic drivers previous version 19.1 and the problem is just gone.

[ASell]

Windows 7 32 & 64-bit drivers https://downloadcenter.intel.com/download/18713/Network-Adapter-Driver-for-Windows-7- here and for Windows 8 and later /thread/ here (I suppose).

[st4]

Hi AJK47,

The latest driver version 20 is downloadable at

https://downloadcenter.intel.com/download/18713/Network-Adapter-Driver-for-Windows-7- Intel® Download Center

hope this helps.

rgds,

wb

[AKaga1]

Thank you for the responses to try and help us resolve this matter. Unfortunately after installing the latest proset drivers you have linked the problem persists just the same as Hlidskjalf. Installed as admin and restarted to be sure the effects were made to the system. Here are the latency results after the install:

With the device ENABLED, the latency is still high in the red and is unsuitable for audio playback over a USB audio interface (I have tried more than one)

With the device DISABLED, the problem goes away and audio playback is normal and desired

It would appear the new update is just for the proset drivers and not the NIC drivers themselves. I believe I have the most up to date drivers of the NIC. If not please post a link to the newest version.

Here are the latencyMon results

Again we see here ndis.sys is the culprit for high execution times. I believe this is the latest driver as well.

Please let me know If i can supply anymore information to help resolve this matter. As of now the problem still persists even with the latest proset update you have linked above.

[st4]

Hi AJK47,

Thank you for taking time to test. . Let me further check on this.

thanks,

wb

[AKaga1]

Thank you for your continued to assistance on this matter. I just want to make sure one point is made very clear. As it stands, the current ProSet sotware (20.0.10.) and Driver (2.10.29.0) revision for the 82579V DO NOT affect the onboard audio. So if I plug in headphones or a mic to the onboard audio controller I have no difficulty with audio playback. The problem occurs with audio playback over a USB audio interface. The drivers currently make any audio USB interface unusable as the audio distortion is awful, near constant pops and cracks over my speakers. I've looked into my ASIO drivers and USB drivers and neither of them have anywhere near the execution time as ndis.sys. So for some reason whatever is going on with the NIC drivers is causing audio latency on the USB bus. If you have any further questions please let me know.

[TGav]

Hello. I am experiencing exactly the same issues as AJK47. I will not post the LatencyMon data as they are identical, using the same NIC/drivers, Win 7 64bit, x79. I too have adjusted as many settings as are available, power options, etc to no avail.

While AJK47 uses USB audio, I can confirm the problem is not USBaudio exclusive but also with PCI pro level ASIO sound card from RME via multichannel ADAT. These cards are industry standard and specifically manufactured for professional near zero latency audio recording. They are not toys.I am used to 32-64 buffer multitrack recording/playback without a glitch

While this audio workstation (used in a pro studio) usually remains offline there are several applications requiring online authorization upon launch thus internet access, however briefly, is essential even on a majority offline machine. Disabling the driver solves the problem but I just cannot go back and forth to device manager 2 or three times simply to launch my DAW and multiple plugins.

The current Intel drivers render the audio engine useless while they are active.

Thanks.

[AKaga1]

Thanks for the response Gav. I'm certainly glad I didn't invest in a PCIe Audio card. I also happened to be looking at RME cards from sweetwater. I've tried several USB interfaces (Focusrite Scarlett, traktor S4 and an Apogee DAC) same problem. Its curious that your PCIe audio interface is affected by latency but yet my onboard sound for my gaming headset is unaffected. So If I'm playing games there is no difficulty but If I open ableton or want to mix with my traktor S4 or CDJ's I can't, the audio distortion as a result of the latency is too awful out of my studio monitors. I've also tried adjusting my sample rate and latency on the cards to compensate and nothing seems to do the trick. Disabling the nic or unplugging my ethernet every time I want to use an audio interface is out of the question, there has to be a software fix.

[FFeld]

Hello everybody,

Just found this thread, and thought I might share my findings.

I just reinstalled Win7 x64 on my audio machine, and first tried the v20 Intel LAN Drivers - both with and without PROSet extensions. in both cases, I got periodical dpc spikes of ~6500ms every few seconds, just like on the screenshot posted a few replies earlier. I then uninstalled the v20 drivers and installed 19.1 from Intel Download Center, which gave me 2 single spikes during installation, (one directly after driver installation, second one directly after installation of proset extension), but that was it - since then it looks like this:

which is perfect (screenshot was taken while PC was idle - normally, one could observe 6400ms spikes with v20 drivers!).

Please Intel, look into this regression - compare changes done since 19.1 version.

The pops and crackles while using my Steinberg UR44 USB interface were really serious, they could be heard every few seconds even while listening to music even without low latency ASIO - I looked into this because I had cracks and pops even while using youtube!

[st4]

Hi Florian,F

We are still checking on this, thank you for the information.

rgds,

wb

[st4]

Hi AJK47.

Just to give you an update, we are in the process of reviewing the changes made between the driver versions. Please use version 19.1 for the meantime since this is the version that works for you.

rgds,

wb

[AKaga1]

Thank you for the continued assistance on this matter. I have download and installed the 19.1 proset drivers and I can confirm that the problem does not affect this version, so it should be suitable for now. Please let me know if you should find a fix for the current version.

[rj4]

Hi I am having the exact same problem.

And I have another problem the file inside for windows 8.1(https://downloadcenter.intel.com/download/24134/Network-Adapter-Driver-for-Windows-8-1- Intel® Download Center) is actually version 19.3 so I cannot get the 19.1 please fix it.

[ASell]

Any solution/news on the DPC latency problem? How far away is a new NIC driver release we can try out?

[st4]

Hi Hlidskjalf,

Currently you can use version 19.1. We will check on this.

rgds,

wb

[tstob]

I had horrible latency issues using the latest 20.0 driver, went back to 19.1 and all is fixed. I can listen to music again!

[st4]

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

[PPete12]

Thank you very much for the reply. I too have the DPC latency issue with my Asus P8z77-i deluxe. How do i disable ME? I cannot find an option in the bios settings.

[st4]

Hi smakkerlak,

Press CTRL-P is one way to enter the ME BIOS. However, 3rd party system vendor might have a different setup, you may check with Asus support on how to enter ME setup on your Asus P8z77.

rgds,

wb

[PPete12]

I looked into the management engine firmware and drivers, but I have no idea if I can just flash the latest 8.xx 1.5m firmware or if I have to stick with whatever is part of the latest bios for my motherboard. I don't know if it would do any good either.

Can ME somehow be disabled from software?

Current info:

Driver version: 11.0.0.1133

Firmware version: 8.1.0.1248

While I wait for Asus support to get back to me, I tried changing AlternateSemaphoreDelay without luck.

If anyone else needs to find the number of their NIC, start msinfo32, go to Components -> Network -> Adapter and find the name of your NIC in the list. Just below, the number for your NIC is "index". I'm on Windows 7, but I assume this works for 8 as well.

[st4]

Hi smakkertak,

The ME is to be disabled in BIOS.

rgds,

wb

[PPete12]

Asus replied that there is no way to disable ME on this board, so its 19.1 for me. There's some info around on modifying firmware yourself but that seems like too much work

Thank you very much for your answers.