measuring interrupt latency - VxWorks

This is a discussion on measuring interrupt latency - VxWorks ; I was wondering if anyone had success measuring interrupt latency using timers in VxWorks on either a Intel x86 or PowerPC board. If so it would be wonderful if you could let me how you had done so. I tried ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: measuring interrupt latency

  1. measuring interrupt latency

    I was wondering if anyone had success measuring interrupt latency
    using timers in VxWorks on either a Intel x86 or PowerPC board. If so
    it would be wonderful if you could let me how you had done so. I tried
    using auxiliary clock interrupt to measure this using sysTimestamp
    drivers and sys clock as timing sources, but was unsuccessful with it.
    I am aware that it is possible to get an accurate measurement using
    oscilloscope or logical analyzer but I would prefer a more automated
    way of measuring interrupt latency using timers.

    Also to be more specific here, by interrupt latency what I mean here
    is the time between the interrupt signaling to when the C routine
    connected to the interrupt service vector starts executing. So
    according to this definition it should include the latency due to the
    controller as well as the time to execute intEnt (otherwise referred
    to as interrupt prologue), which saves the registers and masks the
    interrupts.


  2. Re: measuring interrupt latency

    On Jun 15, 10:43 pm, eshwa...@gmail.com wrote:
    > I was wondering if anyone had success measuring interrupt latency
    > using timers in VxWorks on either a Intel x86 or PowerPC board. If so
    > it would be wonderful if you could let me how you had done so. I tried
    > using auxiliary clock interrupt to measure this using sysTimestamp
    > drivers and sys clock as timing sources, but was unsuccessful with it.
    > I am aware that it is possible to get an accurate measurement using
    > oscilloscope or logical analyzer but I would prefer a more automated
    > way of measuring interrupt latency using timers.
    >
    > Also to be more specific here, by interrupt latency what I mean here
    > is the time between the interrupt signaling to when the C routine
    > connected to the interrupt service vector starts executing. So
    > according to this definition it should include the latency due to the
    > controller as well as the time to execute intEnt (otherwise referred
    > to as interrupt prologue), which saves the registers and masks the
    > interrupts.


    Just to bring this topic back to see if anyone has tried something
    similar. Also if anyone has any tips or pointers in this regard please
    let me know.


  3. Re: measuring interrupt latency

    On Jun 20, 5:49 pm, eshwa...@gmail.com wrote:
    > On Jun 15, 10:43 pm, eshwa...@gmail.com wrote:
    >
    >
    >
    > > I was wondering if anyone had success measuring interrupt latency
    > > using timers in VxWorks on either a Intel x86 or PowerPC board. If so
    > > it would be wonderful if you could let me how you had done so. I tried
    > > using auxiliary clock interrupt to measure this using sysTimestamp
    > > drivers and sys clock as timing sources, but was unsuccessful with it.
    > > I am aware that it is possible to get an accurate measurement using
    > > oscilloscope or logical analyzer but I would prefer a more automated
    > > way of measuring interrupt latency using timers.

    >
    > > Also to be more specific here, by interrupt latency what I mean here
    > > is the time between the interrupt signaling to when the C routine
    > > connected to the interrupt service vector starts executing. So
    > > according to this definition it should include the latency due to the
    > > controller as well as the time to execute intEnt (otherwise referred
    > > to as interrupt prologue), which saves the registers and masks the
    > > interrupts.

    >
    > Just to bring this topic back to see if anyone has tried something
    > similar. Also if anyone has any tips or pointers in this regard please
    > let me know.


    Software cannot possibly measure the time between interrupt signaling
    and any component of interrupt handling.
    If a device asserts its interrupt input to an interrupt controller,
    and the controller has that particular input masked -- i.e. because
    there is currently a higher priority active interrupt -- there's no
    way for software to measure the resultant delay.
    Similarly, the interrupt controller might inflict no (or very little)
    latency in passing an interrupt signal to the CPU int input, but the
    CPU may have interrupts masked.
    Again, no way for software to know anything about that.
    I could imagine an interrupt controller that has a high resolution
    timer integrated and some way to latch the timer when a given input
    goes active.
    But I've never heard of such a device.
    Bottom line is, given your definition of latency, you need hardware to
    measure it.

    HTH,
    GV




  4. Re: measuring interrupt latency

    On 2007-06-20, eshwar.s@gmail.com wrote:
    > On Jun 15, 10:43 pm, eshwa...@gmail.com wrote:
    >> Also to be more specific here, by interrupt latency what I mean here
    >> is the time between the interrupt signaling to when the C routine
    >> connected to the interrupt service vector starts executing. So
    >> according to this definition it should include the latency due to the
    >> controller as well as the time to execute intEnt (otherwise referred
    >> to as interrupt prologue), which saves the registers and masks the
    >> interrupts.

    >
    > Just to bring this topic back to see if anyone has tried something
    > similar. Also if anyone has any tips or pointers in this regard please
    > let me know.


    I have done something similar, but not with vxWorks.

    For TURBOchannel, a previous employer designed a piece of hardware
    specifically to measure interrupt latency. It consisted primarily of
    some counters. You'd load it with a downcount. Once the count expired,
    it would generate an interrupt and start counting up. The ISR could read
    the counter to determine how much time had expired since the interrupt.

    I used it to take a look at interrupt latencies on Ultrix on MIPS, OSF/1
    on Alpha, and VMS on Alpha. Results were:

    - VMS interrupt latency is outstanding. Very fast regardless of how
    loaded the machine is.

    - X Windows on Unix does terrible things to interrupt latency. I don't
    know if it's gotten better; this was a long time ago. X Windows on
    VMS *doesn't* do terrible things to interrupt latency.

    - OSF/1 of that era had a very nasty bug that disabled interrupts for
    a long time at task termination. The amount of time depended upon how
    much memory had been allocated by the task. By writing suitably
    obnoxious code, it was possible to have interrupts disabled for so
    long that a 16-byte FIFO on a serial port running at 300 baud was
    not enough. They fixed that.

    - VMS interrupt latency started getting more variable as the kernel
    moved to C. Coincidence?

    I must have measured VAX/VMS latency, but nothing using this particular
    design comes to mind. I did have some interesting results comparing the
    latency of the VAXstation 4000/60 with the much faster 4000/90, but that
    was with an oscilloscope and a SCSI interface. The 4000/60 had *much* better
    interrupt latency than the 4000/90.
    --
    roger ivie
    rivie@ridgenet.net

  5. Re: measuring interrupt latency

    On Jun 20, 3:09 pm, gvarndell wrote:
    > On Jun 20, 5:49 pm, eshwa...@gmail.com wrote:
    >
    >
    >
    > > On Jun 15, 10:43 pm, eshwa...@gmail.com wrote:

    >
    > > > I was wondering if anyone had success measuring interrupt latency
    > > > using timers in VxWorks on either a Intel x86 or PowerPC board. If so
    > > > it would be wonderful if you could let me how you had done so. I tried
    > > > using auxiliary clock interrupt to measure this using sysTimestamp
    > > > drivers and sys clock as timing sources, but was unsuccessful with it.
    > > > I am aware that it is possible to get an accurate measurement using
    > > > oscilloscope or logical analyzer but I would prefer a more automated
    > > > way of measuring interrupt latency using timers.

    >
    > > > Also to be more specific here, by interrupt latency what I mean here
    > > > is the time between the interrupt signaling to when the C routine
    > > > connected to the interrupt service vector starts executing. So
    > > > according to this definition it should include the latency due to the
    > > > controller as well as the time to execute intEnt (otherwise referred
    > > > to as interrupt prologue), which saves the registers and masks the
    > > > interrupts.

    >
    > > Just to bring this topic back to see if anyone has tried something
    > > similar. Also if anyone has any tips or pointers in this regard please
    > > let me know.

    >
    > Software cannot possibly measure the time between interrupt signaling
    > and any component of interrupt handling.
    > If a device asserts its interrupt input to an interrupt controller,
    > and the controller has that particular input masked -- i.e. because
    > there is currently a higher priority active interrupt -- there's no
    > way for software to measure the resultant delay.
    > Similarly, the interrupt controller might inflict no (or very little)
    > latency in passing an interrupt signal to the CPU int input, but the
    > CPU may have interrupts masked.
    > Again, no way for software to know anything about that.
    > I could imagine an interrupt controller that has a high resolution
    > timer integrated and some way to latch the timer when a given input
    > goes active.
    > But I've never heard of such a device.
    > Bottom line is, given your definition of latency, you need hardware to
    > measure it.
    >
    > HTH,
    > GV


    Hi GV, What I was think was having a timer generating interrupts
    periodically, I can figure out the interrupt latency since I would
    know the time when the interrupt was supposed to be asserted. Also
    inside the ISR i can get another timestamp, this is the time when the
    interrupt actually occurs. The difference between the 2 will give the
    ISR latency. I used the auxiliary interrupts to generate the
    interrupts which I used systimestamp to get the values, but I am not
    getting correct results. I am not sure whats causing the problem. If
    you think there is a problem in this methodology kindly let me know.
    Thanks.


  6. Re: measuring interrupt latency

    On Jun 20, 3:09 pm, gvarndell wrote:
    > On Jun 20, 5:49 pm, eshwa...@gmail.com wrote:
    >
    >
    >
    > > On Jun 15, 10:43 pm, eshwa...@gmail.com wrote:

    >
    > > > I was wondering if anyone had success measuring interrupt latency
    > > > using timers in VxWorks on either a Intel x86 or PowerPC board. If so
    > > > it would be wonderful if you could let me how you had done so. I tried
    > > > using auxiliary clock interrupt to measure this using sysTimestamp
    > > > drivers and sys clock as timing sources, but was unsuccessful with it.
    > > > I am aware that it is possible to get an accurate measurement using
    > > > oscilloscope or logical analyzer but I would prefer a more automated
    > > > way of measuring interrupt latency using timers.

    >
    > > > Also to be more specific here, by interrupt latency what I mean here
    > > > is the time between the interrupt signaling to when the C routine
    > > > connected to the interrupt service vector starts executing. So
    > > > according to this definition it should include the latency due to the
    > > > controller as well as the time to execute intEnt (otherwise referred
    > > > to as interrupt prologue), which saves the registers and masks the
    > > > interrupts.

    >
    > > Just to bring this topic back to see if anyone has tried something
    > > similar. Also if anyone has any tips or pointers in this regard please
    > > let me know.

    >
    > Software cannot possibly measure the time between interrupt signaling
    > and any component of interrupt handling.
    > If a device asserts its interrupt input to an interrupt controller,
    > and the controller has that particular input masked -- i.e. because
    > there is currently a higher priority active interrupt -- there's no
    > way for software to measure the resultant delay.
    > Similarly, the interrupt controller might inflict no (or very little)
    > latency in passing an interrupt signal to the CPU int input, but the
    > CPU may have interrupts masked.
    > Again, no way for software to know anything about that.
    > I could imagine an interrupt controller that has a high resolution
    > timer integrated and some way to latch the timer when a given input
    > goes active.
    > But I've never heard of such a device.
    > Bottom line is, given your definition of latency, you need hardware to
    > measure it.
    >
    > HTH,
    > GV


    Hi GV, What I was thinking was to have a timer generating interrupts
    periodically, I can figure out the interrupt latency since I would
    know the time when the interrupt was supposed to be asserted. Also
    inside the ISR i can get another timestamp, this is the time when the
    interrupt actually occurs. The difference between the 2 will give the
    ISR latency. I used the auxiliary interrupts to generate the
    interrupts which I used systimestamp to get the values, but I am not
    getting correct results. I am not sure whats causing the problem. If
    you think there is a problem in this methodology kindly let me know.
    Thanks.


  7. Re: measuring interrupt latency

    On Tue, 26 Jun 2007 23:05:35 +0000, eshwar.s wrote:
    ....

    > Hi GV, What I was thinking was to have a timer generating interrupts
    > periodically, I can figure out the interrupt latency since I would
    > know the time when the interrupt was supposed to be asserted. Also
    > inside the ISR i can get another timestamp, this is the time when the
    > interrupt actually occurs. The difference between the 2 will give the
    > ISR latency. I used the auxiliary interrupts to generate the
    > interrupts which I used systimestamp to get the values, but I am not
    > getting correct results. I am not sure whats causing the problem. If
    > you think there is a problem in this methodology kindly let me know.
    > Thanks.


    I've done this before, and the method basically works. There is a
    sampling problem involving harmonics of your period. For
    example, if you set an N usec period, and decided you were getting M usec
    of interrupt latency, you could be off by up to (N-M).

    Varying the period can help; however to do that you have to be on the CPU
    [ unless you have a very fancy timer chip ] which is a dependency on
    the interrupt latency; a sort of false autonomy.

    An improvement is to successively halve your period until you start
    missing interrupts, then gradually increase it until you don't. At that
    point, you have basically saturated the CPU at your interrupt priority.
    If you make yours the lowest priority interrupt, then you will have a more
    effective profile of the maximum continuous interrupt rate; highest will
    give you the maximum burst interrupt rate.

    You can make your interrupt schedule a task, and use the same
    method to determine the scheduling latency. Again, making it the lower
    than all 'useful' tasks and higher than same will tell you your maximum
    continuous and burst rates.

    happy sampling.....

+ Reply to Thread