none
IRQL elevation - impacts RRS feed

  • Question

  • Hi,

    I need to synchronize OS time with FW with maximal precision.

    The level I running when I sample the OS time (by KeQuerySystemTimePrecise for Win8 and upper, and KeQuerySystemTime for lower) is DPC.

    I want to stop interrupts from my hardware and elevate the code of sampling the OS time + write to FW the current timestamp to be run in interrupt level,

    so I can be sure the timestamp was sent as soon as possible. Do I need to be afraid of this action? what can it impact on?

    What about elevate for level higher than interrupt level without stopping interrupts?  this timestamp  intended for camera precision, how can I decide what should be more precise? camera (that I won't want it to be shake) or for example mouse?

    Thanks,

    Shosho

    Sunday, December 20, 2015 6:34 AM

Answers

  • Great. Then you get a very small latency of ISR and even smaller latency of accessing the device registers (*)

    So in your ISR call either QPC or KeQueryInterruptTimePrecise and write the result to your device. The device should have a 64-bit counter with programmable rate (so you can set it to the PerformanceFrequency) or fixed 100 ns, to match units of KeQueryInterruptTimePrecise.

    Or v.v, read the timer from your device and correlate it to the Windows time.

    To calibrate the conversion between Windows and device timers you can use a busy loop, for a short time.

    (*) Of course this can be affected by various power states, and remember that Windows Is Not A Real Tiime OS.

    -- pa

    Sunday, December 27, 2015 10:56 AM

All replies

  • What you're trying to do is to "hook" the Windows timer interrupt and write the updated time to your device immediately after the timer interrupt. AFAIK there's no documented way to do this. At most, you can set a periodic timer and get the wall time in the callback (QPC or KeQuerySystemTimePrecise). The timer DPC will be delayed by random reasons, of course

    What about elevate for level higher than interrupt level without stopping interrupts?

    The IRQL concept in Windows means exactly that: if you elevate to certain level, all interrupts of this level and below are stopped.

     this timestamp  intended for camera precision

    What does this mean? Does the camera send its own timestamp back with the image and you want to correlate it with the local PC time?  and how the mouse is involved in this? does you device also send input events with timestamp?

     -- pa

    Sunday, December 20, 2015 9:57 AM
  • The camera gets data from my FW. this data is sent + timestamp of the time it was sent, so the camera can arrange the date it gets according to this timestamp. The mouse is not involved directly, but if I elevate for high IRQL it can stop the interrupts for the mouse if its interrupt level is less\equal to the certain level I chose to elevate to, right? so what I ask is if I can decide what is more important and if I can impact more devices without be aware of it...

    Shosho

    Sunday, December 20, 2015 10:50 AM
  • Ah, ok. Can you remind what is the h/w interface of your device (what is connected to the PC) - USB or PCI?

    When you "write the time" to the device, what the latency could be? USB has certain latency, and there's a special type of pipe, isochronous, to cope with latency and jitter.

    -- pa 

    Sunday, December 20, 2015 11:27 AM
  • It's PCI device.
    Sunday, December 27, 2015 8:15 AM
  • Great. Then you get a very small latency of ISR and even smaller latency of accessing the device registers (*)

    So in your ISR call either QPC or KeQueryInterruptTimePrecise and write the result to your device. The device should have a 64-bit counter with programmable rate (so you can set it to the PerformanceFrequency) or fixed 100 ns, to match units of KeQueryInterruptTimePrecise.

    Or v.v, read the timer from your device and correlate it to the Windows time.

    To calibrate the conversion between Windows and device timers you can use a busy loop, for a short time.

    (*) Of course this can be affected by various power states, and remember that Windows Is Not A Real Tiime OS.

    -- pa

    Sunday, December 27, 2015 10:56 AM
  • why don't use KeQuerySystemTimePrecise? and is it ok to use it in interrupt level? if I send this timestamp for example each 1 second, can't it impact the other devices in the platform? is it safe to use it in interrupt level?
    Sunday, December 27, 2015 1:18 PM
  • Yes, sorry, I actually meant KeQuerySystemTimePrecise . Yes it can be called from DIRQL.

    -- pa

    Sunday, December 27, 2015 3:37 PM
  • why don't use KeQuerySystemTimePrecise?

    Yes, my apologies, this is what I meant.

    ( all my recent replies are deleted...  I wonder who could do that ;)

    -- pa

    Tuesday, December 29, 2015 7:19 PM