> If you had actually took the trouble to look at the code I was
> referring to , you would see that it does exactly that.
Sorry Michael, I apologise for having not copied the right test for a
comparison with my variant and RTAI.
However I got first the suggestion from Tomasz Motilesky much time ago
and after all the jitter fuzz on this newsgroup I also received the
following message from Manoj Apte:
"
The MARUTI operating system group at U maryland has been doing that. In
addition to an early interrupt, they also ensure that the time
critical code is preloaded into the cache by the first interrupt, and
then go into a busy wait till the exact time.
However, they have a peak jitter of close to 2us. But it was 75ns in
most
cases.(15clocks on a 200mhz ppro)
"
MARUTI is a truly hard real time jewill, I discovered it after reading a
nice book on it, and hard real time OSes in general. I got it from them
but I must admit that it was to much for me to chew, so I went to RTL,
that better suited my bare DOS background.
I still believe that 15-30 usecs are a lot, about 1500 floating
add-mult, at least for my applications that can accept some jitter.
Recall that for such a trick you must use a oneshot scheduler and that
gives a further overhead, especially if you are using many tasks. In my
opinion we are overtalking about it just because a few people are using
RTL for sizable applications. In fact the discussions on this mailing
lists are mostly on test cases and problem that could be better solved
by a simpler interrupt RTL handler, without any scheduler.
Moreover those using Linux for digital controllers should recall that is
max jitters of a few tens of us happen just now and then. Often you are
using high control rate for precision purposes but the system bandwith
is well below that rate and easily smoothes off such a jitter.
Otherwise I'm wondering why people using all the stuff for DDNC (direct
numerical control) on precise profiling machine tools where so unkind
not to be at the forefront of alarming us on that problem. So I remain
of the idea that if you need a lower jitter you need another hardware
solution.
In any case if out there there's anybody that want to implement such a
thing on my variant I recall that is trivial. Just install the following
signal function while using the oneshot scheduler:
static void free_the_jitter(void)
{
while (rdtsc() < rt_whoami()->resume_time +
nano2count(MAX_JITTER_IN_NANOSEC));
}
and start periodic tasks in advance of
nano2count(MAX_JITTER_IN_NANOSEC).
The new release of RTAI (rtai-0.1) will have a jitter_free_sw to show
that for a multi tasks square wave generator, both for UP and SMP.
Ciao, Paolo.
--- [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/
