F5F Stay Refreshed Software Operating Systems Is there a problem with my latency?

Is there a problem with my latency?

Is there a problem with my latency?

S
skiXtreme
Junior Member
7
09-16-2026, 02:48 AM
#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:mmConfuseds) 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 _________________________________________________________________________________________________________
S
skiXtreme
09-16-2026, 02:48 AM #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:mmConfuseds) 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 _________________________________________________________________________________________________________

D
DaaarkPlayer
Member
153
09-18-2026, 01:20 AM
#2
Try updating your Ethernet or Wi-Fi drivers because it is better for your computer even if you don't have any. In my experience, Nvidia is always at the top so that isn't necessarily a sign to blame some of the answers in this could help. What are specs of the PC?
D
DaaarkPlayer
09-18-2026, 01:20 AM #2

Try updating your Ethernet or Wi-Fi drivers because it is better for your computer even if you don't have any. In my experience, Nvidia is always at the top so that isn't necessarily a sign to blame some of the answers in this could help. What are specs of the PC?

W
WaterLily2003
Senior Member
648
09-18-2026, 01:56 AM
#3
32gb ddr4 3600hz 12700k 3080 graphics card, 12gb of weirdly slow ram. After a few restarts and a clean reinstall of nvidia minus the geforce experience app, things seem to have stabilized. ~2 hour latencymon run with the largest interrupt at ~350 microseconds, compared to 15000 microseconds in previous runs. I followed an ~80 page optimization guide that tried many methods including processor power state (which I already set back then but important to do if you face this issue) and core unparking etc etc. I'm not sure what actually fixed the problem or if it will stay stable forever, but regardless this guide helped me a lot with understanding realtime audio on windows or any operating system or Glitch Free - Cantabile - Software for Performing Musicians
W
WaterLily2003
09-18-2026, 01:56 AM #3

32gb ddr4 3600hz 12700k 3080 graphics card, 12gb of weirdly slow ram. After a few restarts and a clean reinstall of nvidia minus the geforce experience app, things seem to have stabilized. ~2 hour latencymon run with the largest interrupt at ~350 microseconds, compared to 15000 microseconds in previous runs. I followed an ~80 page optimization guide that tried many methods including processor power state (which I already set back then but important to do if you face this issue) and core unparking etc etc. I'm not sure what actually fixed the problem or if it will stay stable forever, but regardless this guide helped me a lot with understanding realtime audio on windows or any operating system or Glitch Free - Cantabile - Software for Performing Musicians

B
baldchin
Junior Member
31
09-25-2026, 12:21 AM
#4
Do you have an address for it?
B
baldchin
09-25-2026, 12:21 AM #4

Do you have an address for it?

_
_K33P_
Member
80
09-26-2026, 12:47 PM
#5
LatencyMon showed that DPC run time for dxgkrnl.sys caused the biggest delay. Since that code lives in your graphics driver, uninstalling and reinstalling it might fix things. The system driver is actually called by the Nvidia card driver (nvlddmkm.sys), so if you have problems there, they are coming from the GPU. You should also check for hard page faults. After 9 minutes of testing, you got over 5000 of them on a huge 32GB drive—that's too many. The System process took the hit with 3845 faults. A steady high number usually means your RAM is running low. When you run out of memory, things slow down because the computer has to wait longer for data. You can check this by opening Task Manager, going to Performance, clicking Memory on the left, and taking a picture of the numbers at the bottom.
_
_K33P_
09-26-2026, 12:47 PM #5

LatencyMon showed that DPC run time for dxgkrnl.sys caused the biggest delay. Since that code lives in your graphics driver, uninstalling and reinstalling it might fix things. The system driver is actually called by the Nvidia card driver (nvlddmkm.sys), so if you have problems there, they are coming from the GPU. You should also check for hard page faults. After 9 minutes of testing, you got over 5000 of them on a huge 32GB drive—that's too many. The System process took the hit with 3845 faults. A steady high number usually means your RAM is running low. When you run out of memory, things slow down because the computer has to wait longer for data. You can check this by opening Task Manager, going to Performance, clicking Memory on the left, and taking a picture of the numbers at the bottom.

M
marzing22
Member
191
09-28-2026, 12:20 PM
#6
It is located at the very end of the message, just like this: Glitch Free - Cantabile - a program that helps musicians play without errors.
M
marzing22
09-28-2026, 12:20 PM #6

It is located at the very end of the message, just like this: Glitch Free - Cantabile - a program that helps musicians play without errors.

S
SuperHenrique
Junior Member
11
10-03-2026, 07:48 PM
#7
i have this problem consistently indeed. My latency issue is solved but the page faults remain stupidly high - the sources changing usually from chrome or whatever game I play during tests. https://drive.google.com/file/d/1G1svoR-...sp=sharing heres that screenshot.
S
SuperHenrique
10-03-2026, 07:48 PM #7

i have this problem consistently indeed. My latency issue is solved but the page faults remain stupidly high - the sources changing usually from chrome or whatever game I play during tests. https://drive.google.com/file/d/1G1svoR-...sp=sharing heres that screenshot.

M
Misli
Member
110
10-04-2026, 03:31 AM
#8
That isn't a problem, but if your computer is slow or laggy, you should check the old logs for more info.
M
Misli
10-04-2026, 03:31 AM #8

That isn't a problem, but if your computer is slow or laggy, you should check the old logs for more info.

M
MikaMash
Member
51
10-05-2026, 10:18 PM
#9
I need to look at the last two numbers if my games or sounds sound stuttery. I don't feel much lag, just some popping noises that I mentioned earlier, and those issues seem to be gone after all the recent changes.
M
MikaMash
10-05-2026, 10:18 PM #9

I need to look at the last two numbers if my games or sounds sound stuttery. I don't feel much lag, just some popping noises that I mentioned earlier, and those issues seem to be gone after all the recent changes.

A
AlphaSlayer74
Junior Member
4
10-05-2026, 11:09 PM
#10
What do you want to see in those numbers are the Committed values*. The left Commit number tells you exactly how much virtual storage Windows has used right now. The right number shows the absolute maximum amount of virtual storage Windows can ever use. If that left-hand commit number keeps going up faster than your installed RAM (shown at top right), then you don't have enough memory and processes are moving to a slow place called paging - which adds delay. This is unlikely on a 32GB system, but it's still possible. You also need to check that Windows says all 32GB of RAM are available. It's possible one stick is broken and just sitting there unused. I think the fix involved using DDU (a clean-up tool) and reinstalling the graphics driver. That was where the long waiting process happened. * Some very detailed explanations if you want them

A definition first; threads talk about memory, so they need more than what's available then they ask for extra. Windows talks about virtual storage (which is RAM plus a disk file called paging). For our purposes, we treat memory = virtual storage. When any thread wants to grab more memory it must get permission from the Windows Memory Manager. As long as the current amount used plus the size of what's requested doesn't exceed the max allowed limit, Windows will let them and add that request to the current total. The current commit value is simply how much space Windows has given you permission to use right now. Note that committed memory just means virtual storage that is allocated; it doesn't mean any part of it is actually being used yet. None of it might end up being used at all, for example. However, virtual storage must exist somewhere, and that's either in physical RAM or in the paging file on your hard drive. (The max Committed value is just the sum of your installed RAM plus the current size of the paging file; the paging file can grow bigger in some situations). When a thread wants to use any of this allocated memory Windows has to find free pages in RAM where to store it. If RAM is being completely full then some other, less often used pages will get copied out to the paging file and those RAM pages will be used instead for that thread's data. If that thread doesn't touch that memory for a while, and if RAM is still being fully used, eventually the pages holding that thread's data will get copied out to the paging file to make room for another thread's data. When the original thread later wants to read from that old memory spot Windows has to first put the thread in a waiting state. Then it must find where the data was copied out on disk, locate some free pages in RAM (which might mean copying out another thread's unused pages), and then actually load those pages into physical RAM. Only then can the Memory Manager stop the wait and let the thread keep running. All that waiting time is latency - the amount of time your thread wasn't actually working when it needed to be doing so. In a 32GB system I wouldn't expect to see this kind of demand paging because 32GB of RAM shouldn't be fully utilized unless you're running lots of virtual machines, obviously. It's important to realize that paging happens for other reasons too. Threads can choose to page out unused parts of their own code and data, and Windows can also choose to page out parts of its own system files and data. This means not all of the paging you see in that LatencyMon report is necessarily demand paging.
A
AlphaSlayer74
10-05-2026, 11:09 PM #10

What do you want to see in those numbers are the Committed values*. The left Commit number tells you exactly how much virtual storage Windows has used right now. The right number shows the absolute maximum amount of virtual storage Windows can ever use. If that left-hand commit number keeps going up faster than your installed RAM (shown at top right), then you don't have enough memory and processes are moving to a slow place called paging - which adds delay. This is unlikely on a 32GB system, but it's still possible. You also need to check that Windows says all 32GB of RAM are available. It's possible one stick is broken and just sitting there unused. I think the fix involved using DDU (a clean-up tool) and reinstalling the graphics driver. That was where the long waiting process happened. * Some very detailed explanations if you want them

A definition first; threads talk about memory, so they need more than what's available then they ask for extra. Windows talks about virtual storage (which is RAM plus a disk file called paging). For our purposes, we treat memory = virtual storage. When any thread wants to grab more memory it must get permission from the Windows Memory Manager. As long as the current amount used plus the size of what's requested doesn't exceed the max allowed limit, Windows will let them and add that request to the current total. The current commit value is simply how much space Windows has given you permission to use right now. Note that committed memory just means virtual storage that is allocated; it doesn't mean any part of it is actually being used yet. None of it might end up being used at all, for example. However, virtual storage must exist somewhere, and that's either in physical RAM or in the paging file on your hard drive. (The max Committed value is just the sum of your installed RAM plus the current size of the paging file; the paging file can grow bigger in some situations). When a thread wants to use any of this allocated memory Windows has to find free pages in RAM where to store it. If RAM is being completely full then some other, less often used pages will get copied out to the paging file and those RAM pages will be used instead for that thread's data. If that thread doesn't touch that memory for a while, and if RAM is still being fully used, eventually the pages holding that thread's data will get copied out to the paging file to make room for another thread's data. When the original thread later wants to read from that old memory spot Windows has to first put the thread in a waiting state. Then it must find where the data was copied out on disk, locate some free pages in RAM (which might mean copying out another thread's unused pages), and then actually load those pages into physical RAM. Only then can the Memory Manager stop the wait and let the thread keep running. All that waiting time is latency - the amount of time your thread wasn't actually working when it needed to be doing so. In a 32GB system I wouldn't expect to see this kind of demand paging because 32GB of RAM shouldn't be fully utilized unless you're running lots of virtual machines, obviously. It's important to realize that paging happens for other reasons too. Threads can choose to page out unused parts of their own code and data, and Windows can also choose to page out parts of its own system files and data. This means not all of the paging you see in that LatencyMon report is necessarily demand paging.