To: linux-kernel@vger.kernel.org
From: =?iso-8859-1?q?M=E5ns_Rullg=E5rd?= <mru@mru.ath.cx>
Subject: Re: [ANNOUNCE] Linux 2.6 Real Time Kernel
Date: Sat, 09 Oct 2004 21:38:41 +0200
Message-ID: <yw1xvfdjadha.fsf@mru.ath.cx>
References: <41677E4D.1030403@mvista.com> <416822B7.5050206@opersys.com>
 <1097346628.1428.11.camel@krustophenia.net>
 <20041009212614.GA25441@tier.local>
 <1097350227.1428.41.camel@krustophenia.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through
 Obscurity, linux)
Cancel-Lock: sha1:E8b0XazoLhwa+r6p/pPC/M5Xb4w=
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1033
Lines: 21

Lee Revell <rlrevell@joe-job.com> writes:

>> > > 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.

Sure, but running for a zillion cycles without breaking some limit
doesn't guarantee that it never will happen.  Being able to give such
a guarantee is what determinism is about.

-- 
M?ns Rullg?rd
mru@mru.ath.cx

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