Re: [ANNOUNCE] Linux 2.6 Real Time Kernel

[stefan . eletzhofer]

On Sat, Oct 09, 2004 at 03:30:27PM -0400, Lee Revell wrote:
> On Sat, 2004-10-09 at 17:26, stefan.eletzhofer@xxxxxxxxxxxxx wrote:
> > On Sat, Oct 09, 2004 at 02:30:28PM -0400, Lee Revell wrote:
> > > On Sat, 2004-10-09 at 13:41, Karim Yaghmour wrote:
> > > > Sven-Thorsten Dietrich wrote:
> > > > >     - Voluntary Preemption by Ingo Molnar
> > > > >     - IRQ thread patches by Scott Wood and Ingo Molnar
> > > > >     - BKL mutex patch by Ingo Molnar (with MV extensions)
> > > > >     - PMutex from Germany's Universitaet der Bundeswehr, Munich
> > > > >     - MontaVista mutex abstraction layer replacing spinlocks with mutexes
> > > > 
> > > > To the best of my understanding, this still doesn't provide deterministic
> > > > hard-real-time performance in Linux.
> > > 
> > > Using only the VP+IRQ thread patch, I ran my RT app for 11 million
> > > cycles yesterday, with a maximum delay of 190 usecs.  How would this not
> > > satisfy a 200 usec hard RT constraint?
> > 
> > I think the keyword here is "deterministic", isn't it?
> 
> Well, depends what you mean by deterministic.  Some RT apps only require
> an upper bound on response time.  This is a form of determinism.

Yes. But can you give that upper bound "a priori", that is w/o doing
measurements with your application?

Without that I think its impossible to get _guaranteed_ upper
bounds, regardles of the application running. I think thats what
"hard real-time" is all about.

Stefan

> 
> Lee 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Stefan Eletzhofer
InQuant Data GBR
http://www.inquant.de
+49 (0) 751 35 44 112 
+49 (0) 171 23 24 529 (Mobil)
+49 (0) 751 35 44 115 (FAX)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/