Re: preempt rt in commercial use

[Armin Steinhoff <armin@steinhoff.de>]

Hi Steven,

I don't know what a "long" deadline is ... is is something like this:
http://harolds-planet.blogspot.com/2006/02/how-to-deal-with-deadlines.html

Cheers

--Armin

PS: I think you mean a time range where results are treated as delivered 
timely ?



Steven Rostedt wrote:
> On Thu, 2010-09-16 at 08:27 -0700, Nivedita Singhvi wrote:
>> Steven Rostedt wrote:
>>
>>> Hardware that is less complex is easier to mathematically prove that it
>>> will do what you expect to do in all cases, than hardware that is over
>>> engineered, just like software.
>>>
>>> I hold that PREEMPT_RT is not soft real time, but is hard real time
>>> designed. That is, we can't prove that it is hard real time, but any
>>> time we find a case that the software can break its deterministic
>>> result, it is a bug and needs to be fixed. (aka, a system failure).
>> Which serves to highlight my point about using these terms -- you're
>> the terms "hard" and "soft" in a different way than a previous poster.
>> (Assuming "hard real time designed" can get mistaken for "hard real time".
> Hard and soft are relative terms.
>
>> You're saying it's hard because we intend it to meet system deadlines
>> (regardless of deadline??), and it's a bug if it doesn't.
> heh, no. The "regardless of deadlines" was not what I meant. I meant "we
> have determined that the worse case runtime is X+delta, and if we run
> within that time the system works". The deadlines are determined at
> system design based on the hardware and software used. If you can not
> make a deadline at design time, you go back to the drawing board.
>
> It's all about determinism.
>
>> The previous poster in this list was using it to imply guarantees of
>> of very specific response times (<  xxx us).
>>
>> You really, really have to talk about the specifics of the environment,
>> the requirements, the application needs, etc. And I'm missing about
>> half a dozen "really"'s there.
> Note, I'm not sure you implied that vanilla Linux being fast enough can
> be considered "real-time" for long deadlines. If that's the case, it is
> wrong. A simple classic case of priority inversion will cause the system
> to fail no matter how long the deadlines are.
>
> -- Steve
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>