interrupt duration

Joel Sherrill joel.sherrill at OARcorp.com
Fri May 11 12:36:36 UTC 2001


Andrew Maximov wrote:
> 
> RTEMS: rtems-4.5.0
> BSP: pc586
> 
> I have a question about interrupt duration.
> I change irq_asm.S for interrupt duration measurement.
> This is a result of interrupt duration measurement.
> 
> IRQ0  - 4596784 ticks ( rdtsc intstruction )
> IRQ1  - 0
> ...
> IRQ10 - 8321/4601374 ( this is my device )
> ...
> IRQ15 - 0
> 
> By default all IRQs has equal priority, therefore
> IRQ10 can be interrupted by IRQ0. And process time of
> IRQ10 is increasing.
> I solved this problem by increasing priority of IRQ10.
> But why IRQ0 has such long process time ?
> IRQ0 handler call rtems_clock_tick().

First doesn't rdtsc read the number of CPU cycles
since power up?  That means that 8321 is only
about 8.3 microseconds for a 100 Mhz part or
2.1 for a 400 Mhz part.

On the i386, interrupts do not nest unless the handlers
make special provisions to lower interrupts.  If you
think you are measuring nested interrupts, then
my suspicion is that your start/end time marks are 
not matched like you think.

rtems_clock_tick() has a O(n) in it based upon the number
of time events that fire at the same clock tick.  For example,
if the delay for 10 tasks ends on the same clock tick, there
will be 10 unblocking operations.  But I doubt this is
what you are seeing.  
 
>   ------------------------------------------------------------------------
>                 Name: irq_asm.S
>    irq_asm.S    Type: unspecified type (application/octet-stream)
>             Encoding: quoted-printable

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985



More information about the users mailing list