LatencyMon issue ?

T

TempLate_YT

11-05-2021, 04:11 PM #1

I've been experiencing some random pops in my recordings on my apollo, I ran into a bunch of performance guides but I am yet to get a good score on latencymon.
I'm not extremely knowledgeable on what I am looking at and would appreciate any help.
_________________________________________________________________________________________________________
CONCLUSION
_________________________________________________________________________________________________________
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 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:09:11 (h:mm Confused s) on all processors.
_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name: MUSICBOX
OS version: Windows 11, 10.0, version 2009, build: 22631 (x64)
Hardware: MS-7D25, Micro-Star International Co., Ltd.
BIOS: 1.90
CPU: GenuineIntel 12th Gen Intel® Core™ i7-12700K
Logical processors: 12
Processor groups: 1
Processor group size: 12
RAM: 32555 MB total
_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed (WMI): 3610 MHz
Reported CPU speed (registry): 3610 MHz
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): 14992.30
Average measured interrupt to process latency (µs): 4.522634
Highest measured interrupt to DPC latency (µs): 168.40
Average measured interrupt to DPC latency (µs): 2.066979
_________________________________________________________________________________________________________
REPORTED ISRs
_________________________________________________________________________________________________________
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): 52.000554
Driver with highest ISR routine execution time: ndis.sys - Network Driver Interface Specification (NDIS), Microsoft Corporation
Highest reported total ISR routine time (%): 0.000903
Driver with highest ISR total time: ndis.sys - Network Driver Interface Specification (NDIS), Microsoft Corporation
Total time spent in ISRs (%) 0.001518
ISR count (execution time <250 µs): 84300
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-1000 µs): 0
ISR count (execution time 1000-2000 µs): 0
ISR count (execution time 2000-4000 µs): 0
ISR count (execution time >=4000 µs): 0
_________________________________________________________________________________________________________
REPORTED DPCs
_________________________________________________________________________________________________________
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): 273.358449
Driver with highest DPC routine execution time: nvlddmkm.sys - NVIDIA Windows Kernel Mode Driver, Version 546.33 , NVIDIA Corporation
Highest reported total DPC routine time (%): 0.018044
Driver with highest DPC total execution time: dxgkrnl.sys - DirectX Graphics Kernel, Microsoft Corporation
Total time spent in DPCs (%) 0.055974
DPC count (execution time <250 µs): 764246
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-10000 µs): 2
DPC count (execution time 1000-2000 µs): 0
DPC count (execution time 2000-4000 µ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: system
Total number of hard pagefaults 5551
Hard pagefault count of hardest hit process: 3845
Number of processes hit: 44
_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s): 4.686338
CPU 0 ISR highest execution time (µs): 52.000554
CPU 0 ISR total execution time (s): 0.026861
CPU 0 ISR count: 19116
CPU 0 DPC highest execution time (µs): 273.358449
CPU 0 DPC total execution time (s): 1.004371
CPU 0 DPC count: 336948
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s): 2.20380
CPU 1 ISR highest execution time (µs): 31.436565
CPU 1 ISR total execution time (s): 0.013984
CPU 1 ISR count: 13714
CPU 1 DPC highest execution time (µs): 99.303047
CPU 1 DPC total execution time (s): 0.565943
CPU 1 DPC count: 86755
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s): 1.839657
CPU 2 ISR highest execution time (µs): 34.270360
CPU 2 ISR total execution time (s): 0.010193
CPU 2 ISR count: 9863
CPU 2 DPC highest execution time (µs): 263.864266
CPU 2 DPC total execution time (s): 0.390764
CPU 2 DPC count: 59585
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s): 1.645355
CPU 3 ISR highest execution time (µs): 34.501385
CPU 3 ISR total execution time (s): 0.007483
CPU 3 ISR count: 8014
CPU 3 DPC highest execution time (µs): 91.239335
CPU 3 DPC total execution time (s): 0.357476
CPU 3 DPC count: 54686
_________________________________________________________________________________________________________
CPU 4 Interrupt cycle time (s): 1.636308
CPU 4 ISR highest execution time (µs): 26.031579
CPU 4 ISR total execution time (s): 0.009014
CPU 4 ISR count: 8193
CPU 4 DPC highest execution time (µs): 88.017729
CPU 4 DPC total execution time (s): 0.349644
CPU 4 DPC count: 53774
_________________________________________________________________________________________________________
CPU 5 Interrupt cycle time (s): 1.653419
CPU 5 ISR highest execution time (µs): 50.131856
CPU 5 ISR total execution time (s): 0.014679
CPU 5 ISR count: 10368
CPU 5 DPC highest execution time (µs): 92.160665
CPU 5 DPC total execution time (s): 0.382545
CPU 5 DPC count: 63259
_________________________________________________________________________________________________________
CPU 6 Interrupt cycle time (s): 1.640633
CPU 6 ISR highest execution time (µs): 32.165651
CPU 6 ISR total execution time (s): 0.012071
CPU 6 ISR count: 8999
CPU 6 DPC highest execution time (µs): 92.933518
CPU 6 DPC total execution time (s): 0.354719
CPU 6 DPC count: 59485
_________________________________________________________________________________________________________
CPU 7 Interrupt cycle time (s): 1.560002
CPU 7 ISR highest execution time (µs): 44.0
CPU 7 ISR total execution time (s): 0.006123
CPU 7 ISR count: 6033
CPU 7 DPC highest execution time (µs): 98.316898
CPU 7 DPC total execution time (s): 0.278446
CPU 7 DPC count: 45412
_________________________________________________________________________________________________________
CPU 8 Interrupt cycle time (s): 0.667016
CPU 8 ISR highest execution time (µs): 0.0
CPU 8 ISR total execution time (s): 0.0
CPU 8 ISR count: 0
CPU 8 DPC highest execution time (µs): 31.423269
CPU 8 DPC total execution time (s): 0.004522
CPU 8 DPC count: 1120
_________________________________________________________________________________________________________
CPU 9 Interrupt cycle time (s): 0.710008
CPU 9 ISR highest execution time (µs): 0.0
CPU 9 ISR total execution time (s): 0.0
CPU 9 ISR count: 0
CPU 9 DPC highest execution time (µs): 28.123546
CPU 9 DPC total execution time (s): 0.004713
CPU 9 DPC count: 1031
_________________________________________________________________________________________________________
CPU 10 Interrupt cycle time (s): 0.733357
CPU 10 ISR highest execution time (µs): 0.0
CPU 10 ISR total execution time (s): 0.0
CPU 10 ISR count: 0
CPU 10 DPC highest execution time (µs): 35.285319
CPU 10 DPC total execution time (s): 0.004890
CPU 10 DPC count: 1386
_________________________________________________________________________________________________________
CPU 11 Interrupt cycle time (s): 0.746052
CPU 11 ISR highest execution time (µs): 0.0
CPU 11 ISR total execution time (s): 0.0
CPU 11 ISR count: 0
CPU 11 DPC highest execution time (µs): 48.548476
CPU 11 DPC total execution time (s): 0.003684
CPU 11 DPC count: 807
_________________________________________________________________________________________________________

Reply

F

futurehero

11-06-2021, 09:13 AM #2

Updating your Ethernet or Wi-Fi drivers is recommended, regardless of the device you use.
Based on my experience, Nvidia often performs well, so it doesn't necessarily indicate they're at fault.
Some of these responses might be useful.
What are the specifications of the PC?

Reply

Y

yJaaoxD

11-08-2021, 03:45 AM #3

32gb ddr4 3600
12700k
3080 12gb
after several restarts and a nVidia DDU reinstall (excluding the GeForce Experience app), the machine seems stable.
~2 hour latencymon run with the biggest interrupt around 350 microseconds, much lower than the previous 15000 microseconds.
I followed an 80-page optimization guide covering various techniques such as processor power states and core unparking—methods I had already tried but found useful.
I’m not certain what resolved the problem or if it will remain stable long-term, but this guide was very helpful for handling real-time audio on Windows or other OSes.
Glitch Free - Cantabile - Software for Performing Musicians

Reply

G

Gustavgurra03

11-08-2021, 07:25 AM #4

do you have a link to that?

Reply

D

Dil2601

11-09-2021, 08:19 PM #5

The main factor affecting latency, as shown by the LatencyMon results, was the DPC execution time in dxgkrnl.sys. The DPC code resides within the device driver, so updating or reinstalling the graphics driver via DDU likely resolved the issue.

It's important to note that dxgkrnl.sys refers to the Windows DirectX driver, but it actually invokes nvlddmkm.sys, which is the Nvidia graphics driver—this could be the source of any issues.

You may also want to consider the frequency of hard page faults. During testing, you recorded 5551 hard page faults in just over 9 minutes, which is unusually high for a 32GB system. The System process experienced the most faults with 3845. A consistently high number of hard page faults strongly suggests RAM is running low; this can lead to increased latency since each fault adds processing delay. You might want to check Task Manager, go to the Performance tab, click the Memory icon on the left, and take a screenshot showing the bottom figures.

Reply

D

DerNeueDoktor

11-09-2021, 09:16 PM #6

It is located at the end of the reply, but here:
Glitch Free - Cantabile - Software for Performing Musicians

Reply

C

CAMOOO

11-15-2021, 07:43 PM #7

I'm facing the same issue repeatedly. My latency problem is fixed, but page faults keep being very high, especially when switching sources like Chrome or playing games during tests.

Reply

Z

zLeoZiin

12-01-2021, 01:01 AM #8

There's no issue there, you might want to look at that memory data when you're seeing lagging.

Reply

F

Fully

12-02-2021, 05:43 PM #9

You should review the last two digits if you notice stuttering in game or processing sound. You mentioned no lag beyond the audio pops you set earlier, and these issues have been resolved after recent changes.

Reply

P

Pangaea_

12-03-2021, 12:00 AM #10

What you should focus on within those figures is the committed values*. The left commit figure represents the virtual storage Windows has pledged at the present time. The right figure indicates the upper limit of virtual storage Windows can ever pledge.

If the value shown on the left side (currently committed virtual storage) consistently exceeds your installed RAM (located at the top right), you are running low on memory and processes are paging, which leads to slower performance. This scenario is rare on a system with 32GB, though not impossible.

It's also crucial to verify that Windows acknowledges all 32GB of RAM as available. It's conceivable that one RAM module might be faulty or unused.

The approach that helped was employing DDU and reinstalling the graphics driver, which resolved the persistent DPC issue.
*
For those who want more insight, here are some additional details:
First, let's clarify: threads refer to memory usage. If they require more, Windows allocates extra RAM. Virtual storage—comprising RAM and the paging file—is what we're discussing. For our purposes, memory equals virtual storage.

When a thread needs more memory, it requests permission from the Windows Memory Manager. As long as the sum of the current commit plus the requested size stays within the maximum commit limit, Windows approves the request and adds the requested amount to the existing commitment. The committed value thus reflects the total virtual storage Windows has authorized for use.

Keep in mind that committed memory refers only to allocated virtual storage; it doesn't guarantee immediate usage. A RAM stick might be faulty yet remain unused.

The goal is ensuring that all 32GB of RAM are recognized as available. Sometimes a single faulty stick can prevent full utilization.

Understanding this is key: paging also occurs for reasons beyond demand. Threads can choose to release unused memory, and Windows can do the same. Therefore, not every latency spike you see in the LatencyMon report is due solely to demand paging.

Reply