(I have a feeling this message didn't make it out last time I sent it -
at least I didn't see it come back from the list. Here it is again -
sorry if it's a repeat.)
-Hello All,
I'm getting huge max jitter values (5K-8K uSecs) after the conversion to
the RTL V3 interrupt handle format.
In my application I've been using the old RTL V1 interface for setting
up an interrupt handler. I recently made the switch to RTL version 3, by
changing the call format from the old request_RTirq()to the new format
using rtl_request_irq().
I converted the irq handler to one that wakes the pthread which performs
the IRQ task handling.
When I convert the calls back to the old (original) format the max
jitter numbers are comparable to the original system. The average jitter
time is the same or maybe better in Version 3.
The change in irq handling did not change the jitter timing routine.
I'm on a dual 400MHz Celeron based system running RTL V3.0 below
Mandrake V7.2.
The IRQ is generated by a National Instruments DIO-96 card. Timing of
interrupt is user selectable. Fastest timing is a 50 uSecs period. With
the old irq call the typical averages for period length 50 uSec are
rarely above 7 uSec with max at 45 uSec.
I like the option of creating a pthread and controlling attributes;
which CPU, priority level, etc. I've played with some of these, and
generally any change from the default seems to increase maximum jitter
values.
I do not have a histogram of the jitter times. It may be that once in a
while (~0.5 to 1 sec) there are some dropped interrupts. Since I'm
planning to use the system to control a force-feedback system, those
kind of max jitter times will destroy the experiment.
Has anyone seen this? Suggestions or comments?
Steve
--
----- Steve Work--------
[EMAIL PROTECTED]
802-656-7867 Fax: 656-0747
D205B Given Medical Building
Dept. of Molecular Physiology
UVM, VT, USA 05405
** Home of the Optical Tweezers **
-- [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/rtlinux/
