Ok, misunderstanding, I meant a screenshot of the graphic display.
While we are at it, its worth to check the options, I prefer this one, as it shows the lowest values in microseconds,
compared to processes which have not such a high latency compared to DPC's.
General -> Interrupt to DPC latency
Also useful: to post a copy the text based report (Ctrl-C)
Ideal: also a screenshot of the values under drivers, sorted for highest execution time.
There you can best see, which drivers are spending most time on CPU cores.
Remember, drivers are not interrupted by the process scheduler, they terminate running on a core based on convention, so to say, what the developer coded into the driver...
Here something from me for comparison on an IDLE system, no applications running, no mouse movements.
LatencyMon v6.71, settings (options->general): Interrupt to DPC latency
OS: Windows 10 Professional, v1909
Last Win10 Updates: cumulative update from:
- 2020-03-12: KB4551762
- 2020-03-12: KB4540673
Windows Energy Profile: High Performance (!)
Hardware and drivers:
A) RME Hardware and drivers:
- UFX+, driver 0.9716, Firmware 42
- CPU: Xeon E5-1650v3, 3.6 GHz fix
- GPU: MSI GeForce RTX 2070 SUPER GAMING X TRIO
- nVidia driver: studio driver: 431.70 (variant of nVidia driver with fewer changes and by this hopefully more stability)
See also: https://www.thefpsreview.com/2019/08/12 … ormance/8/
- Mainboard: Supermicro X10DRi-F
- DRAM: 32GB
- System SD: Samsung EVO 860 1TB
EDIT: special HW for connecting / isolating Recording Interface on its own bus:
- Old version of the Sonnet Allegro Pro card with 4x FL1100 USB3 chip (not available anymore)
https://www.heise.de/preisvergleich/son … 79334.html
Advantage of this card: using MSI interrupt scheme which works better / more efficient under higher system/interrupt load.
Win7: needs special driver, Win10: driver included into Windows, but you can also install the latest FL driver.
My system settings (brief overview):
- upgrade installation from Windows 7 Professional
- Administrator account reactivated, my normal user has no admin rights
- used O&O Win10 Shutup to deactivate nearly everything but a few things for a) Administrator and b) my account
- Kaspersky Internet Security (Firewall + AntiVirus)
- Bitsum Parkcontrol: to fine tune power profiles, i.e. to disable CPU core parking for High Performance
- Win10 Enhanced System Settings: optimum performance for Background jobs
My personal preferences to get a more Win7 alike look
Please note: I do not know whether these packages are really "safe", I can only hope...
- Replaced Win10 Startmenue by: StartIsBack++
- Installed 8GadgetPack v31.0.0
Performing Tests with LatencyMon:
If you test a DAW professionally then I would let this test run over daytime to catch any impact of background jobs.
I tested for 10 Minutes which is sufficient to get a 1st impression, most issues show up in that timeframe.
Most important is
- to set the energy profile "High Performance" otherwise you get automatically higher latency
- to test on an IDLE system, to see how loaded your system already is without any application running
- please also no mouse moves during tests, as also this generates interrupts, we really want to see the base load
- best on a freshly bootet system, where you freshly logged in, then wait 1-2 minutes so that all foreground
and background applications had a chance to finalize their start-up
I took a snapshot here of the lowest recurring vallue for interrupt to DPC latency to show by this screenshot how low recurring values are. I didn't take the absolute lowest value around 80 microseconds which has been reached only very few times within the 10min measuring value and thus doesn't have any significance.
In the TAB "Drivers" sort for "Highest Execution time", here you can see that no driver occupied the cpu cores for longer than 302 microseconds. This means your CPU cores are not blocked by drivers and quickly free to be able to work on other processes / applications. Remember: drivers = low level routines, can not be interrupted by the Windows Process Scheduler and thus really can block a core if the driver is badly coded and runs for too long.
If an application / driver, which is audio related, is being scheduled to run on this core, then the likeliness is higher, especially under higher system loads, that audio can not be processes in time.
All OS these days (Windows, Apple) are not designed for real-time processing. The systems simply have enough power so that audio can be processed in time if nothing goes wrong (bad drivers, too high CPU load, too few DRAM (paging/swapping), too low ASIO buffers settings for a given workload, too many background processes, too many tracks with too many VST, too CPU hungry VST or VSTi, ..).
Here an example, what system load this system is able to process without issues: https://www.tonstudio-forum.de/blog/ind … cks-de-en/
And now the screenshot of the Drivers TAB from the same measuring interval of ~10 min:
Here the Report Text copy/paste:
Your system appears to be suitable for handling real-time audio and other tasks without dropouts.
LatencyMon has been analyzing your system for 0:10:43 (h:mm:ss) on all processors.
Computer name: SUPERMICRO
OS version: Windows 10 , 10.0, build: 18363 (x64)
Hardware: Super Server, Supermicro, X10SRi-F
CPU: GenuineIntel Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz
Logical processors: 12
Processor groups: 1
RAM: 32641 MB total
Reported CPU speed: 350 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.
WARNING: the CPU speed that was measured is only a fraction of the CPU speed reported. Your CPUs may be throttled back due to variable speed settings and thermal issues. It is suggested that you run a utility which reports your actual CPU frequency and temperature.
MEASURED INTERRUPT TO DPC LATENCIES
The interrupt to DPC latency reflects the measured interval in which a DPC could execute in response to a hardware request from the moment the interrupt service routine started execution.
Highest measured interrupt to DPC latency (µs): 304,20
Average measured interrupt to DPC latency (µs): 2,954504
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): 219,139143
Driver with highest ISR routine execution time: dxgkrnl.sys - DirectX Graphics Kernel, Microsoft Corporation
Highest reported total ISR routine time (%): 0,063938
Driver with highest ISR total time: dxgkrnl.sys - DirectX Graphics Kernel, Microsoft Corporation
Total time spent in ISRs (%) 0,067101
ISR count (execution time <250 µs): 721298
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): 302,371714
Driver with highest DPC routine execution time: ntoskrnl.exe - NT Kernel & System, Microsoft Corporation
Highest reported total DPC routine time (%): 0,053216
Driver with highest DPC total execution time: Wdf01000.sys - Kernelmodustreiber-Frameworklaufzeit, Microsoft Corporation
Total time spent in DPCs (%) 0,093807
DPC count (execution time <250 µs): 2466253
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-999 µs): 5
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: greenshot.exe
Total number of hard pagefaults 181
Hard pagefault count of hardest hit process: 133
Number of processes hit: 7
PER CPU DATA
CPU 0 Interrupt cycle time (s): 18,982914
CPU 0 ISR highest execution time (µs): 219,139143
CPU 0 ISR total execution time (s): 5,156464
CPU 0 ISR count: 651574
CPU 0 DPC highest execution time (µs): 302,371714
CPU 0 DPC total execution time (s): 7,188289
CPU 0 DPC count: 2454531
CPU 1 Interrupt cycle time (s): 1,903446
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): 11,118286
CPU 1 DPC total execution time (s): 0,000123
CPU 1 DPC count: 46
CPU 2 Interrupt cycle time (s): 2,422555
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): 157,710857
CPU 2 DPC total execution time (s): 0,015474
CPU 2 DPC count: 3103
CPU 3 Interrupt cycle time (s): 2,145480
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): 25,485714
CPU 3 DPC total execution time (s): 0,000369
CPU 3 DPC count: 102
CPU 4 Interrupt cycle time (s): 2,145930
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): 41,076857
CPU 4 DPC total execution time (s): 0,003213
CPU 4 DPC count: 1106
CPU 5 Interrupt cycle time (s): 2,074778
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): 35,643429
CPU 5 DPC total execution time (s): 0,000728
CPU 5 DPC count: 154
CPU 6 Interrupt cycle time (s): 2,241556
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): 42,569143
CPU 6 DPC total execution time (s): 0,004973
CPU 6 DPC count: 1614
CPU 7 Interrupt cycle time (s): 2,048176
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): 27,533143
CPU 7 DPC total execution time (s): 0,000245
CPU 7 DPC count: 65
CPU 8 Interrupt cycle time (s): 2,177056
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): 42,250857
CPU 8 DPC total execution time (s): 0,005124
CPU 8 DPC count: 1434
CPU 9 Interrupt cycle time (s): 2,324331
CPU 9 ISR highest execution time (µs): 4,260857
CPU 9 ISR total execution time (s): 0,021056
CPU 9 ISR count: 69724
CPU 9 DPC highest execution time (µs): 43,30
CPU 9 DPC total execution time (s): 0,005156
CPU 9 DPC count: 1218
CPU 10 Interrupt cycle time (s): 2,302879
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): 41,267429
CPU 10 DPC total execution time (s): 0,011464
CPU 10 DPC count: 2428
CPU 11 Interrupt cycle time (s): 2,112404
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): 41,199143
CPU 11 DPC total execution time (s): 0,002994
CPU 11 DPC count: 457
X10SRi-F, Win10 Pro 1909, Cubase, UFX+, Octamic XTC, ADI-2 Pro FS BE/R BE, RayDAT, ARC USB