Thanks to Victor and Der Herr for good answers on this.
> When a interrupt occurs RTLinux checks if there is a realtime > handler , if there is execute it, if there is not but the interrupts is > marked as a non-RT interrup pend it, the regular ISR will be executed as > soon as Linux gets a time-slot to run. The only hiccup you should be seeing > is the execution time of the interrupt emulation code. Yup. Makes sense now. After researching this a little more after posting, it seems that the hardware latency of interrupts on my system is higher than I'd assumed - I wonder if this is a common misconception, because I've got a PIV system with a local 'APIC' built into the chip, I figured it could handle interrupts with a very low latency - but apparently if you don't have the I/O APIC - APIC bus - local APIC configuration, you are looking at worst case latencies on the order of the legacy PIC... is this an accurate assessment? I know this is really a hardware question, but it does bear directly on timing... > If you want to get a good picture of the timings in RTLinux compile ther > rtl_tracer and add some user events at critical points in your application > this will give you a much better picture as it shows your application in > the RTLinux context, that is you see the sheduler, interrupt related stuff > etc. There is a slight distortion of RT performance due to the tracer but > it is very littl (<5%). I discovered the rtl_intercept function after posting, and the trace points are indeed in the place I need. Previously, I had a couple hardware timers issuing periodic interrupts at comensurate frequencies - the highest frequency one being handled as a real-time interrupt - so now I just have that 1 and drive all the ISR's for the rest with rtl_global_pend_irq() - my worst case timing 'hiccups' are smaller, and now I can understand why. Thanks! -Dave i. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
