Resplendence  
· Home
· About
· Contact

 News & Updates
·News Feed (RSS)    

 Online Store
· Buy Now
· License Types

 Customer
· Customer Login
· Customer Support

 Download
· Free downloads
· Registered customers

 Windows Registry
· Registrar Registry
   Manager

· Registrar Command
   Line Edition


 File Protection
· Undeluxe

 Crash Analysis
· WhoCrashed

 Security Tools
· SanityCheck
· AntiFreeze

 System Monitoring
· WhySoSlow
· LatencyMon
· MultiMon
· DispatchMon
· ObjMon

 Productivity
· ErrorLookup

 Software Bundle
· Power Pack

 Source Code
· Driver source code

 Consultancy
· Driver Development

 Newsletter
If you would like to receive a message now and then about product releases, upgrades and discounts,  then please enter your email address to subscribe to our newsletter. 



·  Introduction
·  How to use
·  Supported OS
·  What's new ?
·  IDLT
·  FAQ
·  Pro version
·  Download


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

 · Introduction
 · Supported Operating Systems
 · Professional Edition
 · What's new ?
 · FAQ
 · How to use LatencyMon
 · CPU Power Management issues
 · Interrupt to user process latencies
 · In Depth Latency Tests
 · SMIs and CPU stalls
 · Technical information


Note: this content is currently being updated.







Copyright © 1997-2017 Resplendence Software Projects Sp. All rights reserved. Privacy Policy.
Page generated on 7/23/2017 9:51:14 PM. Last updated on 9/13/2013 5:52:27 PM.