I have the same issue with the 19.3 drivers. I have the 82579v NIC, with Windows 7 Professional 64-bit.
Thought it was quite surprising to have a 6000 dpc latency spikes every few seconds. Is there no quality control or testing involved?
Hope this will be fixed soon.
Thank you for the information. This information will be shared with the appropriate Intel engineering team.
Can you please provide system configuration information, including make, model, switch information, and any special settings? We are interested in trying to replicate this issue and need more information. For now since SW release 19.1 is working, I recommend continuing to use that for now, while we investigate.
hi, i am using lenovo thinkcentre edge 91z desktop all in one pc.
I understand this is Alpha_Tay's thread, but I myself tried playing around with pretty much all the settings there is for the Intel NIC. I tried changing
speed/duplex mode; resulted in nothing, still huge DPC latencies rendering the computer pretty much unusable for anything except using it as a typing machine.
Interrupt moderation: nothing.
Jumbo packet: nothing.
Performance options / Flow control @ disabled: nothing.
Interrupt moderation rate: tried pretty much all the values; nothing, still DPC spikes all over.
Power management settings: Still problems.
Then I tried the integrated diagnostics (connection/cable/hardware), and it seemed to "halt" the DPC spikes when the diagnostics were performed, but when they were done the DPC spikes was back. If it is of any help I saw that more users at Station-Drivers mention they have the same problem if you scroll down to the comments section. One has an Asus Maximus V Gene. I have a Asus P8Z77-V Pro with Intel 82579V NIC. Other driver versions before has been fine, except 19.3.
Just wanted to add, the DPC latency problem remains with the 19.4 and 19.5 driver that was released only a few days ago! Any clues?
I have been having the same difficulty with my 82579V Gigabit Ethernet Controller (Asus Sabertooth z77) and I have looked all over the place for a solution and have come to the conclusion it is an Intel Driver problem. Interestingly enough, when using my headset (plugged into onboard soundcard) I have no audio latency (pops, hiss, cracks etc.) But when using an external audio card via USB (Traktor Kontrol S4) and JBL speakers I get near constant hissing, crackling, popping, etc. During any kind of audio playback if I disable the ethernet controller the problem goes away. I've tried legacy drivers and the latest drivers from intel and asus website and the problem persists. I've tried disabling power management options on the NIC, flow control, interrupt moderation, etc. still no change. I've tried a clean boot selective startup and still have the same issues.
Here is the report from LatencyMon:
Your system appears to be having trouble handling real-time audio and other tasks. You are likely to experience buffer underruns appearing as drop outs, clicks or pops. One or more DPC routines that belong to a driver running in your system appear to be executing for too long. At least one detected problem appears to be network related. In case you are using a WLAN adapter, try disabling it to get better results. One problem may be related to power management, disable CPU throttling settings in Control Panel and BIOS setup. Check for BIOS updates.
LatencyMon has been analyzing your system for 0:02:16 (h:mm:ss) on all processors.
Computer name: FAMILYROOM-PC
OS version: Windows 7 Service Pack 1, 6.1, build: 7601 (x64)
Hardware: ASUSTeK COMPUTER INC., SABERTOOTH Z77
CPU: GenuineIntel Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz
Logical processors: 8
Processor groups: 1
RAM: 8063 MB total
Reported CPU speed: 3500.0 MHz
Measured CPU speed: 2714.0 MHz (approx.)
Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.
MEASURED INTERRUPT TO USER PROCESS LATENCIES
The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.
Highest measured interrupt to process latency (µs): 4741.053073
Average measured interrupt to process latency (µs): 2.064867
Highest measured interrupt to DPC latency (µs): 4739.882803
Average measured interrupt to DPC latency (µs): 0.890394
Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.
Highest ISR routine execution time (µs): 85.1780
Driver with highest ISR routine execution time: USBPORT.SYS - USB 1.1 & 2.0 Port Driver, Microsoft Corporation
Highest reported total ISR routine time (%): 0.011175
Driver with highest ISR total time: USBPORT.SYS - USB 1.1 & 2.0 Port Driver, Microsoft Corporation
Total time spent in ISRs (%) 0.025574
ISR count (execution time <250 µs): 177052
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-999 µs): 0
ISR count (execution time 1000-1999 µs): 0
ISR count (execution time 2000-3999 µs): 0
ISR count (execution time >=4000 µs): 0
DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.
Highest DPC routine execution time (µs): 4749.947143
Driver with highest DPC routine execution time: ndis.sys - NDIS 6.20 driver, Microsoft Corporation
Highest reported total DPC routine time (%): 0.160918
Driver with highest DPC total execution time: USBPORT.SYS - USB 1.1 & 2.0 Port Driver, Microsoft Corporation
Total time spent in DPCs (%) 0.247017
DPC count (execution time <250 µs): 946386
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-999 µs): 18
DPC count (execution time 1000-1999 µs): 0
DPC count (execution time 2000-3999 µs): 0
DPC count (execution time >=4000 µs): 0
REPORTED HARD PAGEFAULTS
Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.
NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit.
Process with highest pagefault count: chrome.exe
Total number of hard pagefaults 163
Hard pagefault count of hardest hit process: 130
Highest hard pagefault resolution time (µs): 99526.725143
Total time spent in hard pagefaults (%): 0.016530
Number of processes hit: 6
PER CPU DATA
CPU 0 Interrupt cycle time (s): 4.301651
CPU 0 ISR highest execution time (µs): 85.1780
CPU 0 ISR total execution time (s): 0.280134
CPU 0 ISR count: 177052
CPU 0 DPC highest execution time (µs): 4749.947143
CPU 0 DPC total execution time (s): 2.651783
CPU 0 DPC count: 913922
CPU 1 Interrupt cycle time (s): 1.184128
CPU 1 ISR highest execution time (µs): 0.0
CPU 1 ISR total execution time (s): 0.0
CPU 1 ISR count: 0
CPU 1 DPC highest execution time (µs): 52.845143
CPU 1 DPC total execution time (s): 0.002082
CPU 1 DPC count: 463
CPU 2 Interrupt cycle time (s): 1.154260
CPU 2 ISR highest execution time (µs): 0.0
CPU 2 ISR total execution time (s): 0.0
CPU 2 ISR count: 0
CPU 2 DPC highest execution time (µs): 69.809429
CPU 2 DPC total execution time (s): 0.007867
CPU 2 DPC count: 4365
CPU 3 Interrupt cycle time (s): 1.194544
CPU 3 ISR highest execution time (µs): 0.0
CPU 3 ISR total execution time (s): 0.0
CPU 3 ISR count: 0
CPU 3 DPC highest execution time (µs): 43.879143
CPU 3 DPC total execution time (s): 0.001055
CPU 3 DPC count: 334
CPU 4 Interrupt cycle time (s): 0.892084
CPU 4 ISR highest execution time (µs): 0.0
CPU 4 ISR total execution time (s): 0.0
CPU 4 ISR count: 0
CPU 4 DPC highest execution time (µs): 68.956571
CPU 4 DPC total execution time (s): 0.013802
CPU 4 DPC count: 9907
CPU 5 Interrupt cycle time (s): 1.175889
CPU 5 ISR highest execution time (µs): 0.0
CPU 5 ISR total execution time (s): 0.0
CPU 5 ISR count: 0
CPU 5 DPC highest execution time (µs): 51.6980
CPU 5 DPC total execution time (s): 0.001016
CPU 5 DPC count: 132
CPU 6 Interrupt cycle time (s): 1.132131
CPU 6 ISR highest execution time (µs): 0.0
CPU 6 ISR total execution time (s): 0.0
CPU 6 ISR count: 0
CPU 6 DPC highest execution time (µs): 48.118286
CPU 6 DPC total execution time (s): 0.027156
CPU 6 DPC count: 17181
CPU 7 Interrupt cycle time (s): 1.146047
CPU 7 ISR highest execution time (µs): 0.0
CPU 7 ISR total execution time (s): 0.0
CPU 7 ISR count: 0
CPU 7 DPC highest execution time (µs): 70.764286
CPU 7 DPC total execution time (s): 0.001006
CPU 7 DPC count: 133
It would appear ndis.sys is the culprit. As I've said above, regardless of which driver version I'm using the second I disable the NIC the problem goes away. I've tried using drivers with and without the latest version of ProSet, no change.
Here are some pictures to better illustrate the problem
Please let me know if I can provide any additional information or troubleshooting steps. I would really appreciate an official response as this problem is quite annoying and pervasive for many people after spending some time researching it.
Issue is still unresolved. Bumping thread for viability. Would greatly appreciate a response.
Would like to update this thread with more info in hopes of a response from Intel. I've noticed that If I unplug the Ethernet jack while leaving the device enabled the problem goes away. So it would appear that the problem has to do with network activity occurring over the NIC and not the device itself being enabled in device manager. Obviously this does not help if you want to stream any content over the web, which I do primarily. For now I can use itunes with the Ethernet jack unplugged and the symptoms no longer affect playback of media. While I understand on board audio even on high end boards is problematic I am curious if other Asus z77 Sabertooth users have the same problem or if its related to the driver and NIC and not the construction of the board and the lack of isolation for the audio components from the noisy ones.
Is there any fix to this issue ? not only there is DPC problems, the performance is crap with the Intel CT 1GB network cards. with the windows 7 11.0 default driver I'm getting proper speed 949.5mb per second when I'm testing IPERF or MikroTik Bandwidth Test 0.1 . with the 12.11 and higher or something like that I'm getting terrible DPC while doing the test and terrible non steady speed between 750-840mb in the same test above.
Intel, Please answer and fix the issue with proper drivers. cause it happens in Windows 8.1 Default drivers means it's the same drivers you released and the same issues all around. from what it seem it happens with the Intel CT and the Intel(R) 82579LM which I have too onboard Asus P8Z77-V, which has the same lag spikes like the OP and same speed like the CT same as above.
It would appear that there is no response from intel on this matter. Its been 5 months since this thread was started and more than enough detail has been provided to warrant a response other than "this problem has been reported". I guess the problem is with the 82579LM and 82579V onboard NIC drivers. I ventured to guess that poor design of the board left the audio components unisolated from the noisy ones and thus caused latency and interference with audio playback. However after testing using the 3.5mm audio out and mic in jacks with my Cloud HyperX Headset I've determined no problems with audio playback on the front panel audio or rear audio jacks. This is strictly related to audio playback via USB and a soundcard. Doesn't matter what soundcard I use, playback to the speakers is unbearable. Constant audio interrupts in the form of crackling, popping, hissing, etc. I've tested the same speakers (JBL LSR2325) and my soundcard (Traktor Audio S4) on another desktop and laptop with a different onboard NIC and had no problems at all. So I'm back to my initial suspicion, that the drivers for the 82579V are the culprit. Please help Intel!
I think the issue is with the Bus Mastering. the intel 82579 doesn't support it. it takes the interrupts from the CPU. and somehow the new drivers just shows it or might not enable it and have worst performance.
The CT has the Bus Mastering enabled always but has crap performance with the new drivers too, from intel drivers or from windows update drivers, it's the same since 19.5 or something, I think 19.1 works fine, can't be sure already.
Let me know how 19.1 drivers work for you. Thats an interesting idea regarding the Bus Mastering. I would be curious if that was the problem.
Unfortunately still no response from intel...