8 Apr
2005
8 Apr
'05
5:45 p.m.
On Fri, 2005-04-08 at 14:30, Lee Revell wrote:
On Fri, 2005-04-08 at 09:24 -0500, Jan Depner wrote:
Hard realtime has nothing to do with how short the deadlines are, it's
about being able to *guarantee* that you can meet some deadline, IOW the
ability to guarantee that every code path in the kernel is
deterministic. And the RT preempt kernel absolutely can do hard
realtime, down to about 50 usecs (which is the length of time the timer
interrupt, the longest non preemptible path in the kernel, takes to
run).
I do know what hard real-time is - I used to do hard real-time
airborne magnetics/navigation data acquisition systems. That's why I
said guaranteed. You can get 15 microsecond guaranteed out of RT-Linux
though (depending on the hardware of course). However, I'll believe 50
microseconds when I see it run for 30 days doing fairly high bandwidth
data acquisition. BTW, where did you see someone say that they were
guaranteeing 50 microsecond interrupt response? I'd like to read up on
that.
Personally I think you're wasting your time. Ingo's RT preempt patches
let you do hard realtime with Linux using the existing driver base.
I'm not sure why he's trying to do this because for audio the latest
patched kernels appear to be more than adequate. That said, I don't
think you can get a guaranteed 15 microsecond interrupt response with
anyone's patches to the standard kernel. I wouldn't call what we have
now hard real-time. More like soft real-time. Maybe when MontaVista
gets done... Right now all the work that various people have done
to enable hard
realtime on Linux is being ported to the RT preempt kernel. When
MontaVista and others get all their patches in we should be able to meet
even smaller RT constraints.
That's what I'm hoping for. I could probably live with 50
microseconds for most things but there are some systems that require
better.
Jan