Interrupt to user process latencies
Starting with v5, LatencyMon measures interrupt to user process latencies.
The interrupt to process latency reflects the interval in which a usermode application responds to a hardware request, from the moment
an interrupt service routine started execution. In operating system lecture this is sometimes referred to as Process Dispatch Latency.
Only kernel drivers can respond to hardware interrupt signals. When a hardware device sends an interrupt which is received on one of the processors, an interrupt service routine (ISR) is called. The ISR in turn schedules a DPC for deferred processing which in turn is able to wake up a process thread by signalling a dispatcher object such as an event. At this point the application can take over the job of communicating with the device. Because other interrupts can occur and other DPCs can execute during this process of scheduling, it introduces latency. To be able to measure this latency, LatencyMon simulates a typical setup by signaling an interrupt and providing a driver as well as an application that responds to that interrupt signal.
The value that is measured from the moment the interrupt service routine started includes the time required for the system to schedule and execute the DPC plus the time required for an idle thread to wake up. The interrupt to process latency that is measured does not include the interval from the moment the hardware signalled an interrupt until an interrupt service routine started execution (which may be referred to as interrupt latency in certain contexts).
The method of measuring latencies that used a kernel timer that was used in previous versions is still available as an optional feature. However since Windows 8 comes with a new power saving feature called dynamic clock tick as well as a new algorithm for deciding when kernel timer events should actually fire, this method of measuring is no longer practical or useful on Windows 8 and later operating systems.
Note: it is recommended to close all other running programs before running the interrupt to user process latency test, or before interpreting the value that it reports. This test simulates the workings of a real-time audio process. Unlike other tests that LatencyMon performs, it does not make sense to run this test while an audio program is active.
LatencyMon documentation and articles
Note: this content is currently being updated.
Page generated on 11/22/2019 8:32:04 AM. Last updated on 9/17/2019 2:09:47 PM.