* Re: preempt rt in commercial use
2010-09-14 14:21 ` Jeff Angielski
@ 2010-09-14 14:30 ` Nikita V. Youshchenko
2010-09-14 14:49 ` Jeff Angielski
2010-09-14 14:44 ` Pradyumna Sampath
` (3 subsequent siblings)
4 siblings, 1 reply; 66+ messages in thread
From: Nikita V. Youshchenko @ 2010-09-14 14:30 UTC (permalink / raw)
To: Jeff Angielski; +Cc: Robert Schwebel, Raz, linux-rt-users
> >> anyone can say preempt rt is hard real time?
> >
> > Hard realtime has something to do with how you define "missing the
> > deadline". If somebody cuts the cable of your roboter controller in
> > the factory hall, the system misses the deadline. So it is all about
> > probabilities: hard realtime systems have a very, very low probability
> > of missing the deadline. However, in real life systems, it is> 0%.
> >
> > So yes, if you talk about real world, it is hard realtime.
>
> No. Preempt rt it's not hard realtime.
>
> But most people/companies who think they need hard realtime really
> don't. They can live with soft realtime and have a really low
> probability of missing deadlines and having long latencies. For these
> people, the preempt rt is adequate.
Isn't any case where preempt-rt does not behave as hard reatlime a bug in
preempt-rt, that should be reported to this list and eventually fixed?
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: preempt rt in commercial use
2010-09-14 14:30 ` Nikita V. Youshchenko
@ 2010-09-14 14:49 ` Jeff Angielski
2010-09-14 22:20 ` Nivedita Singhvi
2010-09-15 13:33 ` Thomas Gleixner
0 siblings, 2 replies; 66+ messages in thread
From: Jeff Angielski @ 2010-09-14 14:49 UTC (permalink / raw)
To: Nikita V. Youshchenko; +Cc: Robert Schwebel, Raz, linux-rt-users
On 09/14/2010 10:30 AM, Nikita V. Youshchenko wrote:
>>>> anyone can say preempt rt is hard real time?
>>>
>>> Hard realtime has something to do with how you define "missing the
>>> deadline". If somebody cuts the cable of your roboter controller in
>>> the factory hall, the system misses the deadline. So it is all about
>>> probabilities: hard realtime systems have a very, very low probability
>>> of missing the deadline. However, in real life systems, it is> 0%.
>>>
>>> So yes, if you talk about real world, it is hard realtime.
>>
>> No. Preempt rt it's not hard realtime.
>>
>> But most people/companies who think they need hard realtime really
>> don't. They can live with soft realtime and have a really low
>> probability of missing deadlines and having long latencies. For these
>> people, the preempt rt is adequate.
>
> Isn't any case where preempt-rt does not behave as hard reatlime a bug in
> preempt-rt, that should be reported to this list and eventually fixed?
That is a philosophical question for the preempt-rt maintainers.
I *believe* that the design goal for the preempt rt code is to minimize
kernel latency. It's not to make the kernel deterministic to support
hard realtime.
So I don't know if I'd call it a bug, but rather on the wish list for
future enhancements.
--
Jeff Angielski
The PTR Group
www.theptrgroup.com
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: preempt rt in commercial use
2010-09-14 14:49 ` Jeff Angielski
@ 2010-09-14 22:20 ` Nivedita Singhvi
2010-09-15 7:48 ` Armin Steinhoff
2010-09-15 13:33 ` Thomas Gleixner
1 sibling, 1 reply; 66+ messages in thread
From: Nivedita Singhvi @ 2010-09-14 22:20 UTC (permalink / raw)
To: Jeff Angielski
Cc: Nikita V. Youshchenko, Robert Schwebel, Raz, linux-rt-users
On 09/14/2010 07:49 AM, Jeff Angielski wrote:
>> Isn't any case where preempt-rt does not behave as hard reatlime a bug in
>> preempt-rt, that should be reported to this list and eventually fixed?
>
> That is a philosophical question for the preempt-rt maintainers.
>
> I *believe* that the design goal for the preempt rt code is to minimize
> kernel latency. It's not to make the kernel deterministic to support
> hard realtime.
Er, sort of, not quite.
The design goal of the real-time kernel is most certainly to make the
kernel more deterministic, to the extent we can in a general-purpose way.
Determinism = capping max latencies.
It's better to have all hundred iterations of an operation take
45us each than to have 95 iterations take 30us and 5 iterations
take 75us. You want to be able to say, "this operation will take
at _most_ 50us" and have that be as true as possible.
We sacrifice overall throughput (ave latency) for determinism
(low max latency).
Not sure if that's what you intended to say, but hope that helps.
thanks,
Nivedita
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: preempt rt in commercial use
2010-09-14 22:20 ` Nivedita Singhvi
@ 2010-09-15 7:48 ` Armin Steinhoff
2010-09-15 14:09 ` Nivedita Singhvi
0 siblings, 1 reply; 66+ messages in thread
From: Armin Steinhoff @ 2010-09-15 7:48 UTC (permalink / raw)
To: Nivedita Singhvi
Cc: Jeff Angielski, Nikita V. Youshchenko, Robert Schwebel, Raz,
linux-rt-users
Nivedita Singhvi wrote:
> On 09/14/2010 07:49 AM, Jeff Angielski wrote:
>
>>> Isn't any case where preempt-rt does not behave as hard reatlime a
>>> bug in
>>> preempt-rt, that should be reported to this list and eventually fixed?
>>
>> That is a philosophical question for the preempt-rt maintainers.
>>
>> I *believe* that the design goal for the preempt rt code is to minimize
>> kernel latency. It's not to make the kernel deterministic to support
>> hard realtime.
>
> Er, sort of, not quite.
>
> The design goal of the real-time kernel is most certainly to make the
> kernel more deterministic, to the extent we can in a general-purpose way.
>
> Determinism = capping max latencies.
Capping max latencies doesn't help without a good real-time, event
driven scheduler.
But it helps to classify real-time operatings systems as so called
hard or soft real-time operating systems.
IMHO ... there is a common understanding that a RTOS can be
considered as a hard-reatime OS if the
max latency is < 15us because it is able to server 80% (?) of all
hard real-time applications in the field.
All others are considered as soft real-time operating systems. From
this point of view is PREEMPT_RT Linux
a hard real-time OS ... if the hardware base is appropriate.
BTW ... we use PREEMPT_RT Linux as a base for our commercial
solft-PLC called DACHSview: http://steinhoff-automation.com/Programming.htm
>
> It's better to have all hundred iterations of an operation take
> 45us each than to have 95 iterations take 30us and 5 iterations
> take 75us. You want to be able to say, "this operation will take
> at _most_ 50us" and have that be as true as possible.
All these numbers have no meaning if you don't specify the hardware
environment.
--Armin
http://www.steinhoff-automation.com
>
> We sacrifice overall throughput (ave latency) for determinism
> (low max latency).
>
> Not sure if that's what you intended to say, but hope that helps.
>
> thanks,
> Nivedita
>
>
> --
> 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
>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: preempt rt in commercial use
2010-09-15 7:48 ` Armin Steinhoff
@ 2010-09-15 14:09 ` Nivedita Singhvi
2010-09-15 14:45 ` Pradyumna Sampath
2010-09-15 15:38 ` David Kastrup
0 siblings, 2 replies; 66+ messages in thread
From: Nivedita Singhvi @ 2010-09-15 14:09 UTC (permalink / raw)
To: Armin Steinhoff
Cc: Jeff Angielski, Nikita V. Youshchenko, Robert Schwebel, Raz,
linux-rt-users
Armin Steinhoff wrote:
>> Determinism = capping max latencies.
>
> Capping max latencies doesn't help without a good real-time, event
> driven scheduler.
>
> But it helps to classify real-time operatings systems as so called
> hard or soft real-time operating systems.
>
> IMHO ... there is a common understanding that a RTOS can be considered
> as a hard-reatime OS if the
> max latency is < 15us because it is able to server 80% (?) of all
> hard real-time applications in the field.
At some stage this might have been a pretty good response time.
But HW improves by leaps and bounds, and what was considered "fast"
or "real-time" 25 years ago might be your average vanilla desktop
box speed of today.
So, you'd have to define _exactly_ what operation completes
in under 15us? Again, it's these kinds of ambiguities that make
this a very woollen and fuzzy way to talk about subjects and needs
which are usually very precise and critical.
If your OS can support sub-us response times for some required
operation, I expect you wnat to say that, rather than a generic
"hard RT".
> All others are considered as soft real-time operating systems. From
> this point of view is PREEMPT_RT Linux
> a hard real-time OS ... if the hardware base is appropriate.
Right. Regardless of what you call it, I would want the user to
understand very clearly what the OS is capable of, and what it
is not. And whether that meets their application's needs or not.
> BTW ... we use PREEMPT_RT Linux as a base for our commercial
> solft-PLC called DACHSview: http://steinhoff-automation.com/Programming.htm
Very interesting! Thanks for sharing that...
thanks,
Nivedita
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: preempt rt in commercial use
2010-09-15 14:09 ` Nivedita Singhvi
@ 2010-09-15 14:45 ` Pradyumna Sampath
2010-09-16 10:17 ` Daniel James
2010-09-15 15:38 ` David Kastrup
1 sibling, 1 reply; 66+ messages in thread
From: Pradyumna Sampath @ 2010-09-15 14:45 UTC (permalink / raw)
To: Nivedita Singhvi
Cc: Armin Steinhoff, Jeff Angielski, Nikita V. Youshchenko,
Robert Schwebel, Raz, linux-rt-users
Hi all,
On Wed, Sep 15, 2010 at 4:09 PM, Nivedita Singhvi <niv@us.ibm.com> wrote:
> At some stage this might have been a pretty good response time.
> But HW improves by leaps and bounds, and what was considered "fast"
> or "real-time" 25 years ago might be your average vanilla desktop
> box speed of today.
<snip ...>
This has been an interesting conversation. Would be nice to know more
deployments of RT_PREEMPT in various application areas.
I have created a wiki page on http://rt.wiki.kernel.org/ ,
https://rt.wiki.kernel.org/index.php/Systems_based_on_Real_time_preempt_Linux
. Please feel free to update it as and when you encounter / build /
read about interesting usage of RT_PREEMPT.
If its painful for you to login and edit the page, just drop me or
this list a note and either me or someone will update the page.
best regards
/prady
--
http://www.prady.in
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: preempt rt in commercial use
2010-09-15 14:45 ` Pradyumna Sampath
@ 2010-09-16 10:17 ` Daniel James
2010-09-16 10:35 ` Pradyumna Sampath
2010-09-16 15:19 ` Raz
0 siblings, 2 replies; 66+ messages in thread
From: Daniel James @ 2010-09-16 10:17 UTC (permalink / raw)
To: Pradyumna Sampath
Cc: Nivedita Singhvi, Armin Steinhoff, Jeff Angielski,
Nikita V. Youshchenko, Robert Schwebel, Raz, linux-rt-users
Hi Pradyumna,
> I have created a wiki page on http://rt.wiki.kernel.org/ ,
> https://rt.wiki.kernel.org/index.php/Systems_based_on_Real_time_preempt_Linux
> . Please feel free to update it as and when you encounter / build /
> read about interesting usage of RT_PREEMPT.
Here's a more unusual example we have worked on recently - a
multi-microphone hearing aid research platform:
http://www.64studio.com/press_release_mahalia
With six microphones (three per side) you can start to do interesting
things with software algorithms, like selective noise cancellation. A
well-known electronics company is using this system for field trials, in
collaboration with university researchers in Germany.
Cheers!
Daniel
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: preempt rt in commercial use
2010-09-16 10:17 ` Daniel James
@ 2010-09-16 10:35 ` Pradyumna Sampath
2010-09-16 15:19 ` Raz
1 sibling, 0 replies; 66+ messages in thread
From: Pradyumna Sampath @ 2010-09-16 10:35 UTC (permalink / raw)
To: Daniel James
Cc: Nivedita Singhvi, Armin Steinhoff, Jeff Angielski,
Nikita V. Youshchenko, Robert Schwebel, Raz, linux-rt-users
Hi,
On Thu, Sep 16, 2010 at 12:17 PM, Daniel James <daniel@64studio.com> wrote:
> Here's a more unusual example we have worked on recently - a
> multi-microphone hearing aid research platform:
>
> http://www.64studio.com/press_release_mahalia
<snip ..>
This is an interest list as it now is slowly growing to see some cool
products. IMHO, there are several customers for some of these products
who might consider the usage of RT_PREEMPT Linux as one of the USP's
(Unique selling proposition) of the product.
I for one would know some companies in the industrial space might be
interested to buy industrial protocol devices and have RT_PREEMPT
Linux drivers for them upstreamed. So maybe this list might help
potential customers as well.
Nonetheless, from my perspective its just fun to know :-) !
best regards
/prady
--
http://www.prady.in
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: preempt rt in commercial use
2010-09-16 10:17 ` Daniel James
2010-09-16 10:35 ` Pradyumna Sampath
@ 2010-09-16 15:19 ` Raz
1 sibling, 0 replies; 66+ messages in thread
From: Raz @ 2010-09-16 15:19 UTC (permalink / raw)
To: Daniel James; +Cc: linux-rt-users
On Thu, Sep 16, 2010 at 12:17 PM, Daniel James <daniel@64studio.com> wrote:
> Hi Pradyumna,
>
>> I have created a wiki page on http://rt.wiki.kernel.org/ ,
>> https://rt.wiki.kernel.org/index.php/Systems_based_on_Real_time_preempt_Linux
great. this is exactly what i wanted.
thank you.
>> . Please feel free to update it as and when you encounter / build /
>> read about interesting usage of RT_PREEMPT.
>
> Here's a more unusual example we have worked on recently - a
> multi-microphone hearing aid research platform:
>
> http://www.64studio.com/press_release_mahalia
>
> With six microphones (three per side) you can start to do interesting
> things with software algorithms, like selective noise cancellation. A
> well-known electronics company is using this system for field trials, in
> collaboration with university researchers in Germany.
>
> Cheers!
>
> Daniel
>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: preempt rt in commercial use
2010-09-15 14:09 ` Nivedita Singhvi
2010-09-15 14:45 ` Pradyumna Sampath
@ 2010-09-15 15:38 ` David Kastrup
2010-09-15 16:02 ` Nivedita Singhvi
1 sibling, 1 reply; 66+ messages in thread
From: David Kastrup @ 2010-09-15 15:38 UTC (permalink / raw)
To: linux-rt-users
Nivedita Singhvi <niv@us.ibm.com> writes:
> At some stage this might have been a pretty good response time. But
> HW improves by leaps and bounds, and what was considered "fast" or
> "real-time" 25 years ago might be your average vanilla desktop box
> speed of today.
I think you are confused. "fast" and "realtime" are quite unrelated.
The computers used aboard ancient space craft are abysmally slow
compared to today's desktop computers, but certainly operate in
realtime.
It does not matter whether one system can run circles around the other
one as long as any given circle can't be guaranteed to complete in a
specified amount of time.
Realtime recording systems, for example, can't actually be writing to
high performance file systems unless they can work with preallocation.
Hard realtime is not reasonably possible for a lot of tasks on a general
purpose computing device. But there is often a lot you can do to help
it give a better shot at things.
--
David Kastrup
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: preempt rt in commercial use
2010-09-15 15:38 ` David Kastrup
@ 2010-09-15 16:02 ` Nivedita Singhvi
2010-09-15 16:20 ` David Kastrup
0 siblings, 1 reply; 66+ messages in thread
From: Nivedita Singhvi @ 2010-09-15 16:02 UTC (permalink / raw)
To: David Kastrup; +Cc: linux-rt-users
David Kastrup wrote:
> Nivedita Singhvi <niv@us.ibm.com> writes:
>
>> At some stage this might have been a pretty good response time. But
>> HW improves by leaps and bounds, and what was considered "fast" or
>> "real-time" 25 years ago might be your average vanilla desktop box
>> speed of today.
>
> I think you are confused. "fast" and "realtime" are quite unrelated.
Sorry, yes, I know, but was sloppy. And because the whole point
of this thread was to make exactly these things clear, I'll add to
this already monstrously long thread. That was the point of the "or",
that if you have a faster system by several orders of magnititude, you
can effectively put together a box that will meet some application's
"hard" deadlines (which would not have been possible before). As others
commented before in this thread, failing the deadline becomes very,
very, very low probability.
> The computers used aboard ancient space craft are abysmally slow
> compared to today's desktop computers, but certainly operate in
> realtime.
>
> It does not matter whether one system can run circles around the other
> one as long as any given circle can't be guaranteed to complete in a
> specified amount of time.
Right -- but the point was, any HW system can fail, too (very, very
low statistically speaking, but still not 0%). So no system is
impervious to all sources of breakage.
> Realtime recording systems, for example, can't actually be writing to
> high performance file systems unless they can work with preallocation.
>
> Hard realtime is not reasonably possible for a lot of tasks on a general
> purpose computing device. But there is often a lot you can do to help
> it give a better shot at things.
Yep.
thanks,
Nivedita
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: preempt rt in commercial use
2010-09-15 16:02 ` Nivedita Singhvi
@ 2010-09-15 16:20 ` David Kastrup
2010-09-16 0:44 ` Steven Rostedt
0 siblings, 1 reply; 66+ messages in thread
From: David Kastrup @ 2010-09-15 16:20 UTC (permalink / raw)
To: linux-rt-users
Nivedita Singhvi <niv@us.ibm.com> writes:
> David Kastrup wrote:
>>
>> It does not matter whether one system can run circles around the
>> other one as long as any given circle can't be guaranteed to complete
>> in a specified amount of time.
>
> Right -- but the point was, any HW system can fail, too (very, very
> low statistically speaking, but still not 0%). So no system is
> impervious to all sources of breakage.
A hardware failure means that the system is in violation of the system
design. A soft realtime failure means that reality is in violation of
the system design.
You can't shift the blame to another department by claiming that a
mistake could have happened there as well.
--
David Kastrup
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: preempt rt in commercial use
2010-09-15 16:20 ` David Kastrup
@ 2010-09-16 0:44 ` Steven Rostedt
2010-09-16 15:27 ` Nivedita Singhvi
0 siblings, 1 reply; 66+ messages in thread
From: Steven Rostedt @ 2010-09-16 0:44 UTC (permalink / raw)
To: David Kastrup; +Cc: linux-rt-users
On Wed, 2010-09-15 at 18:20 +0200, David Kastrup wrote:
> Nivedita Singhvi <niv@us.ibm.com> writes:
>
> A hardware failure means that the system is in violation of the system
> design. A soft realtime failure means that reality is in violation of
> the system design.
The PREEMPT_RT patch (as I explained in another email) is designed to be
hard real time. Thus, a failure to meet its deadline is a failure in the
system design, just like it would be for hardware.
If you have a extremely complex piece of equipment, it is very hard to
prove that it can meet its deadlines given all circumstances. One reason
that x86 is not very hard real time friendly. The same is true with
software. If it becomes complex, it is very hard to prove that it too
can meet its deadlines in all corner cases. The analogy still holds
true.
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).
-- Steve
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: preempt rt in commercial use
2010-09-16 0:44 ` Steven Rostedt
@ 2010-09-16 15:27 ` Nivedita Singhvi
2010-09-16 17:30 ` Steven Rostedt
0 siblings, 1 reply; 66+ messages in thread
From: Nivedita Singhvi @ 2010-09-16 15:27 UTC (permalink / raw)
To: Steven Rostedt; +Cc: David Kastrup, linux-rt-users
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".
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.
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.
thanks,
Nivedita
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: preempt rt in commercial use
2010-09-16 15:27 ` Nivedita Singhvi
@ 2010-09-16 17:30 ` Steven Rostedt
2010-09-16 19:27 ` Armin Steinhoff
0 siblings, 1 reply; 66+ messages in thread
From: Steven Rostedt @ 2010-09-16 17:30 UTC (permalink / raw)
To: Nivedita Singhvi; +Cc: David Kastrup, linux-rt-users
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
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: preempt rt in commercial use
2010-09-16 17:30 ` Steven Rostedt
@ 2010-09-16 19:27 ` Armin Steinhoff
2010-09-16 19:38 ` Steven Rostedt
0 siblings, 1 reply; 66+ messages in thread
From: Armin Steinhoff @ 2010-09-16 19:27 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Nivedita Singhvi, David Kastrup, linux-rt-users
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
>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: preempt rt in commercial use
2010-09-16 19:27 ` Armin Steinhoff
@ 2010-09-16 19:38 ` Steven Rostedt
0 siblings, 0 replies; 66+ messages in thread
From: Steven Rostedt @ 2010-09-16 19:38 UTC (permalink / raw)
To: Armin Steinhoff; +Cc: Nivedita Singhvi, David Kastrup, linux-rt-users
On Thu, 2010-09-16 at 21:27 +0200, Armin Steinhoff wrote:
> 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
cute.
>
> Cheers
>
> --Armin
>
> PS: I think you mean a time range where results are treated as delivered
> timely ?
Yes, I think people understood what I meant. By "long deadline" I meant
the time needed for an event to happen or critical section to finish is
so large that it should be easy for the event to occur or a critical
section to finish within that time range.
In a rate monotonic scenario, I usually consider 3 time ranges. Period,
deadline and runtime. Where, period >= deadline >= runtime. Usually
runtime is deadline - (enough for some delta). Thus, when I say
deadline, that is just a shorter version of "time it takes where a
deadline must be reached".
-- Steve
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: preempt rt in commercial use
2010-09-14 14:49 ` Jeff Angielski
2010-09-14 22:20 ` Nivedita Singhvi
@ 2010-09-15 13:33 ` Thomas Gleixner
1 sibling, 0 replies; 66+ messages in thread
From: Thomas Gleixner @ 2010-09-15 13:33 UTC (permalink / raw)
To: Jeff Angielski
Cc: Nikita V. Youshchenko, Robert Schwebel, Raz, linux-rt-users
B1;2401;0cOn Tue, 14 Sep 2010, Jeff Angielski wrote:
> On 09/14/2010 10:30 AM, Nikita V. Youshchenko wrote:
> > > > > anyone can say preempt rt is hard real time?
> > > >
> > > > Hard realtime has something to do with how you define "missing the
> > > > deadline". If somebody cuts the cable of your roboter controller in
> > > > the factory hall, the system misses the deadline. So it is all about
> > > > probabilities: hard realtime systems have a very, very low probability
> > > > of missing the deadline. However, in real life systems, it is> 0%.
> > > >
> > > > So yes, if you talk about real world, it is hard realtime.
> > >
> > > No. Preempt rt it's not hard realtime.
> > >
> > > But most people/companies who think they need hard realtime really
> > > don't. They can live with soft realtime and have a really low
> > > probability of missing deadlines and having long latencies. For these
> > > people, the preempt rt is adequate.
> >
> > Isn't any case where preempt-rt does not behave as hard reatlime a bug in
> > preempt-rt, that should be reported to this list and eventually fixed?
>
> That is a philosophical question for the preempt-rt maintainers.
>
> I *believe* that the design goal for the preempt rt code is to minimize kernel
> latency. It's not to make the kernel deterministic to support hard realtime.
The design goal is deterministic behaviour. Not more, not less.
And yes, we aim for hard realtime - as hard as it gets given the
circumstances and for the vast majority of applications.
We do _NOT_ aim for
- a system which provides mathematical prove of it's correctness
simply because that's not feasible.
I know that the purists will answer that such a system can't be
hard real-time by definition, but I can live with that. :)
- the extreme corner cases where response time guarantees in the
single digit microseconds range are required. Simply because we
run on hardware which has already builtin latencies (not
controlable by the OS) in the two digits microseconds range.
> So I don't know if I'd call it a bug, but rather on the wish list for future
> enhancements.
If there is non deterministic behaviour, it's a bug which should be
reported and fixed.
Thanks,
tglx
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: preempt rt in commercial use
2010-09-14 14:21 ` Jeff Angielski
2010-09-14 14:30 ` Nikita V. Youshchenko
@ 2010-09-14 14:44 ` Pradyumna Sampath
2010-09-15 12:48 ` Sergio Ruocco
2010-09-14 14:56 ` Armin Steinhoff
` (2 subsequent siblings)
4 siblings, 1 reply; 66+ messages in thread
From: Pradyumna Sampath @ 2010-09-14 14:44 UTC (permalink / raw)
To: Jeff Angielski
Cc: Robert Schwebel, Raz, Nikita V. Youshchenko, linux-rt-users
Hi,
On Tue, Sep 14, 2010 at 4:21 PM, Jeff Angielski <jeff@theptrgroup.com> wrote:
> No. Preempt rt it's not hard realtime.
>
> But most people/companies who think they need hard realtime really don't.
> They can live with soft realtime and have a really low probability of
> missing deadlines and having long latencies. For these people, the preempt
> rt is adequate.
I agree. Hard, soft ... far too qualitative for a discussion like
this. Numbers, test cases and applications determine different
meanings of these words.
Top copy a phrase from one of the presentations from dresden.
Real-time need not always be real fast.
hard Real-time = Speed + Determinism
So hard real time is a moving target. Would I use RT_PREEMPT to run
servo loops at 60 microseconds on a 160 Mhz powerpc ? Surely not ! Or
not yet.
my 2 cents.
regards
/prady
--
http://www.prady.in
--
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
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: preempt rt in commercial use
2010-09-14 14:44 ` Pradyumna Sampath
@ 2010-09-15 12:48 ` Sergio Ruocco
2010-09-15 12:53 ` Pradyumna Sampath
` (2 more replies)
0 siblings, 3 replies; 66+ messages in thread
From: Sergio Ruocco @ 2010-09-15 12:48 UTC (permalink / raw)
To: Pradyumna Sampath
Cc: Jeff Angielski, Robert Schwebel, Raz, Nikita V. Youshchenko,
linux-rt-users
Pradyumna Sampath wrote:
> I agree. Hard, soft ... far too qualitative for a discussion like
> this. Numbers, test cases and applications determine different
> meanings of these words.
Right. Hard and Soft realtime discussions end up always in useless
infinite loops. The *applications*' *requirements* are hard or soft.
These requirements reflect in the OS, the CPU, the IO devices, and more
typically a convolution of all of them, depending on what the
application does, i.e., the actual sequence of computations, OS
syscalls, IO operations and so on...
> Top copy a phrase from one of the presentations from dresden.
Which presentation? I am curious to read it.
> Real-time need not always be real fast.
"Real fast is not real-time" is a catchy phrase which comes from this
very old workshop:
http://www.langston.com/Papers/uk.pdf
I used it to motivate an investigation in the real-time properties of a
"real fast" microkernel:
http://www.hindawi.com/journals/es/2008/234710.abs.html
Have fun!
Sergio
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: preempt rt in commercial use
2010-09-15 12:48 ` Sergio Ruocco
@ 2010-09-15 12:53 ` Pradyumna Sampath
2010-09-15 14:58 ` Paul E. McKenney
2010-09-15 16:27 ` Sven-Thorsten Dietrich
2 siblings, 0 replies; 66+ messages in thread
From: Pradyumna Sampath @ 2010-09-15 12:53 UTC (permalink / raw)
To: ruocco
Cc: Jeff Angielski, Robert Schwebel, Raz, Nikita V. Youshchenko,
linux-rt-users
Hi,
2010/9/15 Sergio Ruocco <ruocco@disco.unimib.it>:
> Which presentation? I am curious to read it.
http://www.rdrop.com/users/paulmck/realtime/paper/RTvsRF.2009.09.30b.pdf
best regards
/prady
--
http://www.prady.in
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: preempt rt in commercial use
2010-09-15 12:48 ` Sergio Ruocco
2010-09-15 12:53 ` Pradyumna Sampath
@ 2010-09-15 14:58 ` Paul E. McKenney
2010-09-15 16:27 ` Sven-Thorsten Dietrich
2 siblings, 0 replies; 66+ messages in thread
From: Paul E. McKenney @ 2010-09-15 14:58 UTC (permalink / raw)
To: Sergio Ruocco
Cc: Pradyumna Sampath, Jeff Angielski, Robert Schwebel, Raz,
Nikita V. Youshchenko, linux-rt-users
On Wed, Sep 15, 2010 at 02:48:19PM +0200, Sergio Ruocco wrote:
> Pradyumna Sampath wrote:
> > I agree. Hard, soft ... far too qualitative for a discussion like
> > this. Numbers, test cases and applications determine different
> > meanings of these words.
>
> Right. Hard and Soft realtime discussions end up always in useless
> infinite loops. The *applications*' *requirements* are hard or soft.
>
> These requirements reflect in the OS, the CPU, the IO devices, and more
> typically a convolution of all of them, depending on what the
> application does, i.e., the actual sequence of computations, OS
> syscalls, IO operations and so on...
I did a Linux Journal article on this topic a few years ago:
http://www.linuxjournal.com/article/9361
I also did a portion of a short course on this topic last year:
http://www.rdrop.com/users/paulmck/scalability/paper/ACACES2009/4-LKRT.2009.07.16a.pdf
http://www.rdrop.com/users/paulmck/scalability/paper/ACACES2009/5-AppRT.2009.07.17b.pdf
Thanx, Paul
> > Top copy a phrase from one of the presentations from dresden.
>
> Which presentation? I am curious to read it.
>
> > Real-time need not always be real fast.
>
> "Real fast is not real-time" is a catchy phrase which comes from this
> very old workshop:
>
> http://www.langston.com/Papers/uk.pdf
>
> I used it to motivate an investigation in the real-time properties of a
> "real fast" microkernel:
>
> http://www.hindawi.com/journals/es/2008/234710.abs.html
>
> Have fun!
>
> Sergio
> --
> 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
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: preempt rt in commercial use
2010-09-15 12:48 ` Sergio Ruocco
2010-09-15 12:53 ` Pradyumna Sampath
2010-09-15 14:58 ` Paul E. McKenney
@ 2010-09-15 16:27 ` Sven-Thorsten Dietrich
2010-09-16 0:49 ` Steven Rostedt
2 siblings, 1 reply; 66+ messages in thread
From: Sven-Thorsten Dietrich @ 2010-09-15 16:27 UTC (permalink / raw)
To: ruocco
Cc: Pradyumna Sampath, Jeff Angielski, Robert Schwebel, Raz,
Nikita V. Youshchenko, linux-rt-users
On Wed, 2010-09-15 at 14:48 +0200, Sergio Ruocco wrote:
> Pradyumna Sampath wrote:
> > I agree. Hard, soft ... far too qualitative for a discussion like
> > this. Numbers, test cases and applications determine different
> > meanings of these words.
>
> Right. Hard and Soft realtime discussions end up always in useless
> infinite loops. The *applications*' *requirements* are hard or soft.
>
THANK YOU!
The term "RTOS" historically has been a tag used by proprietary vendors
to charge exorbitant fees for their OS.
TODAY,
with embedded shifting towards Linux, there are still a few of these
RTOS vendors, who are using variants of this "fear tactic" with their
customers:
"Linux isn't an RTOS, and it won't be reliable"
This is also key to Klaas's point that most customer's "think" they need
an RTOS. That's typically good marketing to your typical organization
where product management and marketing has been empowered to the point
where they are making software architecture decisions.
OTOH, there are plenty of valid applications for RT, don't
mis-understand. Its just that RTOS is IMO just a totally overmarketed
term to earn premium revenue.
> These requirements reflect in the OS, the CPU, the IO devices, and more
> typically a convolution of all of them, depending on what the
> application does, i.e., the actual sequence of computations, OS
> syscalls, IO operations and so on...
>
And the aggregate latencies either QUALIFY or DISQUALIFY the OS, based
on some degree of qualification. That qual should be extremely rigorous
for "hard RT" and may be less so for "soft RT".
The notion that you can just buy a hard RTOS, that makes guarantees, and
be done with things, is a fantasy.
In the end you will be doing a lot of work on your RTOS (drivers), and
you can screw things up badly.
Or you can qualify Linux. If Linux is good, then you are done,
otherwise, pay for an RTOS or send patches.
Its that simple.
Sven
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: preempt rt in commercial use
2010-09-15 16:27 ` Sven-Thorsten Dietrich
@ 2010-09-16 0:49 ` Steven Rostedt
2010-09-16 5:06 ` David Kastrup
0 siblings, 1 reply; 66+ messages in thread
From: Steven Rostedt @ 2010-09-16 0:49 UTC (permalink / raw)
To: Sven-Thorsten Dietrich
Cc: ruocco, Pradyumna Sampath, Jeff Angielski, Robert Schwebel, Raz,
Nikita V. Youshchenko, linux-rt-users
On Wed, 2010-09-15 at 09:27 -0700, Sven-Thorsten Dietrich wrote:
> Or you can qualify Linux. If Linux is good, then you are done,
> otherwise, pay for an RTOS or send patches.
I have one of the best RTOS systems around. Pay me big bucks and I might
give it to you.
I simply call it... DOS ;-)
-- Steve
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: preempt rt in commercial use
2010-09-16 0:49 ` Steven Rostedt
@ 2010-09-16 5:06 ` David Kastrup
0 siblings, 0 replies; 66+ messages in thread
From: David Kastrup @ 2010-09-16 5:06 UTC (permalink / raw)
To: linux-rt-users
Steven Rostedt <rostedt@goodmis.org> writes:
> On Wed, 2010-09-15 at 09:27 -0700, Sven-Thorsten Dietrich wrote:
>
>> Or you can qualify Linux. If Linux is good, then you are done,
>> otherwise, pay for an RTOS or send patches.
>
> I have one of the best RTOS systems around. Pay me big bucks and I might
> give it to you.
>
> I simply call it... DOS ;-)
The purpose of an operating system is to manage system resources.
Including CPU time. Leaving that task to the user is cheating.
--
David Kastrup
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: preempt rt in commercial use
2010-09-14 14:21 ` Jeff Angielski
2010-09-14 14:30 ` Nikita V. Youshchenko
2010-09-14 14:44 ` Pradyumna Sampath
@ 2010-09-14 14:56 ` Armin Steinhoff
2010-09-14 15:42 ` Patrice Kadionik
2010-09-14 17:38 ` Gregory Haskins
4 siblings, 0 replies; 66+ messages in thread
From: Armin Steinhoff @ 2010-09-14 14:56 UTC (permalink / raw)
To: Jeff Angielski
Cc: Robert Schwebel, Raz, Nikita V. Youshchenko, linux-rt-users
Jeff Angielski wrote:
> On 09/14/2010 05:44 AM, Robert Schwebel wrote:
>> On Tue, Sep 14, 2010 at 11:24:21AM +0200, Raz wrote:
>>> anyone can say preempt rt is hard real time?
>>
>> Hard realtime has something to do with how you define "missing the
>> deadline". If somebody cuts the cable of your roboter controller in the
>> factory hall, the system misses the deadline. So it is all about
>> probabilities: hard realtime systems have a very, very low probability
>> of missing the deadline. However, in real life systems, it is> 0%.
>>
>> So yes, if you talk about real world, it is hard realtime.
>
> No. Preempt rt it's not hard realtime.
True. But show me a single RTOS which provides a real "hard
real-time" operation. They all suffer by the SMI functions, cache
problems or other
resource constrains at hardware level ... specially when they run on
x86 hardware.
>
> But most people/companies who think they need hard realtime really don't.
Missing a deadline by 5us is not a problem for most control
applications ... e.g. the fastes bus cycle of Profinet is today 250us.
> They can live with soft realtime and have a really low probability
> of missing deadlines and having long latencies. For these people, the
> preempt rt is adequate
Yes, more important is an extended range of priorities (up to 99) and
a clean event oriented real-time scheduling.
What we really don't need is the dual kernel concept of RT-LINUX :)
--Armin
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: preempt rt in commercial use
2010-09-14 14:21 ` Jeff Angielski
` (2 preceding siblings ...)
2010-09-14 14:56 ` Armin Steinhoff
@ 2010-09-14 15:42 ` Patrice Kadionik
2010-09-14 17:38 ` Gregory Haskins
4 siblings, 0 replies; 66+ messages in thread
From: Patrice Kadionik @ 2010-09-14 15:42 UTC (permalink / raw)
Cc: linux-rt-users
Le 14/09/2010 16:21, Jeff Angielski a écrit :
> On 09/14/2010 05:44 AM, Robert Schwebel wrote:
>> On Tue, Sep 14, 2010 at 11:24:21AM +0200, Raz wrote:
>>> anyone can say preempt rt is hard real time?
>>
>> Hard realtime has something to do with how you define "missing the
>> deadline". If somebody cuts the cable of your roboter controller in the
>> factory hall, the system misses the deadline. So it is all about
>> probabilities: hard realtime systems have a very, very low probability
>> of missing the deadline. However, in real life systems, it is> 0%.
>>
>> So yes, if you talk about real world, it is hard realtime.
>
> No. Preempt rt it's not hard realtime.
Hi Jeff,
I agree with you.
Saying just realtime makes confusion because people often think hard
realtime in this case. They can also have surprises with they use a soft
realtime OS in this case.
>
> But most people/companies who think they need hard realtime really
> don't. They can live with soft realtime and have a really low
> probability of missing deadlines and having long latencies. For these
> people, the preempt rt is adequate.
Yes. The reflexion to have is: I need realtime. Does my process to
control need hard realtime requirements or just soft realtime is enough?
Can my process to control support to miss some events sometime or not?
Patrice
--
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
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: preempt rt in commercial use
2010-09-14 14:21 ` Jeff Angielski
` (3 preceding siblings ...)
2010-09-14 15:42 ` Patrice Kadionik
@ 2010-09-14 17:38 ` Gregory Haskins
2010-09-14 22:09 ` Nivedita Singhvi
4 siblings, 1 reply; 66+ messages in thread
From: Gregory Haskins @ 2010-09-14 17:38 UTC (permalink / raw)
To: Robert Schwebel, Jeff Angielski
Cc: Nikita V. Youshchenko, Raz, linux-rt-users
>>> On 9/14/2010 at 10:21 AM, in message <4C8F8500.5070002@theptrgroup.com>, Jeff
Angielski <jeff@theptrgroup.com> wrote:
> On 09/14/2010 05:44 AM, Robert Schwebel wrote:
>> On Tue, Sep 14, 2010 at 11:24:21AM +0200, Raz wrote:
>>> anyone can say preempt rt is hard real time?
>>
>> Hard realtime has something to do with how you define "missing the
>> deadline". If somebody cuts the cable of your roboter controller in the
>> factory hall, the system misses the deadline. So it is all about
>> probabilities: hard realtime systems have a very, very low probability
>> of missing the deadline. However, in real life systems, it is> 0%.
>>
>> So yes, if you talk about real world, it is hard realtime.
>
> No. Preempt rt it's not hard realtime.
This is not technically correct, but a common misconception. "Hard" vs "Soft" is a property of the _application_, not the os/platform itself, and it's based on how tolerant a given application is to missed deadlines.
"Hard" might be something like professional lossless audio, nuclear fuel-rod control, bomb-squad robotics, tele-medicine, etc, where the result of a missed deadline can have a serious/unacceptable negative impact (death, injury, SLA failure, etc). "Soft" might be telecom audio, high-frequency financial trading, etc, where misses (crappy audio quality, missed market opportunity, etc) are certainly not desired, but can technically be gracefully recovered from.
Any given platform (os and hardware combo) will have quantifiable performance/latency characteristics. If those characteristics exceed the requirements of your application, they it would generally work to run a "hard rt" application on that platform. If those characteristics <= your app, it probably will not meet your deadlines and therefore, a hard-rt app will fail.
Consider a fictious nuclear fuel rod control applications with requirements for a period of 20s, 500ms dutycycle, and with +- 1s jitter tolerance. Failure means reactor meltdown (this is hard-realtime) yet preempt-rt could certainly handle this. Heck, mainline linux could probably handle this. On the other hand, if anyone out there plans on doing fuel-rod control with software, please tell me so I can leave the continent. ;) But the point is, it's a hard-realtime application and it can be done even with preempt-rt. As you scale the applicaiton's requirements tighter and tighter, you will eventually find the limits of the platform to which it is no longer acceptable to run the application. On modern x86 desktops, these limits are in the order of 10us-150us.
The biggest challenge is _proving_ that a given platform actually possesses the desired performance characteristics. This is especially difficult with preempt-rt given that its based on a general purpose OS (linux) and a large one that that. Smaller, more RT specific os designs may be easier to prove every path has a maximum latency of "X". That said, there are very few products out there that could probably fit that description and most will have trouble proving beyond a shadow of doubt. In addition, the preempt-rt community is very responsive and treats every latency source as a "bug" to be fixed/improved.
So bottom line, if in doubt, I suggest you give preempt-rt a try. Linux in general boasts probably the broadest support profile of any platform out there. In addition, it's configuration is so finely grained that you can probably scale it back to a lean, mean, low-latency environment that will do what you need for perhaps all but the most stringent requirements. Where it wouldn't work, perhaps only dedicated hardware may help anyway.
>
> But most people/companies who think they need hard realtime really
> don't.
I do agree with this statement.
-Greg
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: preempt rt in commercial use
2010-09-14 17:38 ` Gregory Haskins
@ 2010-09-14 22:09 ` Nivedita Singhvi
2010-09-15 6:22 ` Patrice Kadionik
0 siblings, 1 reply; 66+ messages in thread
From: Nivedita Singhvi @ 2010-09-14 22:09 UTC (permalink / raw)
To: Gregory Haskins
Cc: Robert Schwebel, Jeff Angielski, Nikita V. Youshchenko, Raz,
linux-rt-users
On 09/14/2010 10:38 AM, Gregory Haskins wrote:
>> No. Preempt rt it's not hard realtime.
>
> This is not technically correct, but a common misconception. "Hard" vs "Soft" is a property of the _application_, not the os/platform itself, and it's based on how tolerant a given application is to missed deadlines.
>
> "Hard" might be something like professional lossless audio, nuclear fuel-rod control, bomb-squad robotics, tele-medicine, etc, where the result of a missed deadline can have a serious/unacceptable negative impact (death, injury, SLA failure, etc). "Soft" might be telecom audio, high-frequency financial trading, etc, where misses (crappy audio quality, missed market opportunity, etc) are certainly not desired, but can technically be gracefully recovered from.
>
> Any given platform (os and hardware combo) will have quantifiable performance/latency characteristics. If those characteristics exceed the requirements of your application, they it would generally work to run a "hard rt" application on that platform. If those characteristics<= your app, it probably will not meet your deadlines and therefore, a hard-rt app will fail.
>
> Consider a fictious nuclear fuel rod control applications with requirements for a period of 20s, 500ms dutycycle, and with +- 1s jitter tolerance. Failure means reactor meltdown (this is hard-realtime) yet preempt-rt could certainly handle this. Heck, mainline linux could probably handle this. On the other hand, if anyone out there plans on doing fuel-rod control with software, please tell me so I can leave the continent. ;) But the point is, it's a hard-realtime application and it can be done even with preempt-rt. As you scale the applicaiton's requirements tighter and tighter, you will eventually find the limits of the platform to which it is no longer acceptable to run the application. On modern x86 desktops, these limits are in the order of 10us-150us.
>
> The biggest challenge is _proving_ that a given platform actually possesses the desired performance characteristics. This is especially difficult with preempt-rt given that its based on a general purpose OS (linux) and a large one that that. Smaller, more RT specific os designs may be easier to prove every path has a maximum latency of "X". That said, there are very few products out there that could probably fit that description and most will have trouble proving beyond a shadow of doubt. In addition, the preempt-rt community is very responsive and treats every latency source as a "bug" to be fixed/improved.
>
> So bottom line, if in doubt, I suggest you give preempt-rt a try. Linux in general boasts probably the broadest support profile of any platform out there. In addition, it's configuration is so finely grained that you can probably scale it back to a lean, mean, low-latency environment that will do what you need for perhaps all but the most stringent requirements. Where it wouldn't work, perhaps only dedicated hardware may help anyway.
I would go further and say people need to stop using the terms
"hard" and "soft". There isn't a binary yes/no answer to the real-time
requirements spectrum.
Applications can have varying response time requirements, from
microseconds to milliseconds to seconds to minutes as Greg says above.
Applications might have differing penalties for missed deadlines:
* nuclear reactor explodes
* I lose a trade and it costs me money
* I get a slightly different stock price quoted to me
* Justin Bieber sounds a little hoarse
If you're discussing Linux real-time, chances are your application
does not fall in the first one. Typically a very custom engineered
solution (hardware and software) is used for those who have rather
severe constraints.
The concept of "hard" as being mathematically/logically provable
in terms of specs and code examination is nice, but not very practical.
As other people have pointed out frequently, given any system, it's
possible to break its guaranteed deadlines (catastrophic hw failure,
etc.
The real-time Linux patchset (CONFIG_PREEMPT_RT) provides real-time
support in Linux. As you might expect from a general-purpose OS
providing real-time, it's providing increased determinism and better
control over your system (most significantly, your kernel tasks).
A more preemptive kernel and system with better time granularity
provides better real-time response compared to a standard kernel.
It's important to note that we're not providing guarantees. Latency
response time expectations are really based on empirical evidence,
testing with common hw/sw/configurations and debugging issues when
an issue is reported.
Seriously, the terms "hard" and "soft" really only serve to either
confuse or have little value (other than "custom" and "non-custom").
thanks,
Nivedita
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: preempt rt in commercial use
2010-09-14 22:09 ` Nivedita Singhvi
@ 2010-09-15 6:22 ` Patrice Kadionik
[not found] ` <4C90CF71.2050205@us.ibm.com>
2010-09-15 14:08 ` Steven Rostedt
0 siblings, 2 replies; 66+ messages in thread
From: Patrice Kadionik @ 2010-09-15 6:22 UTC (permalink / raw)
Cc: linux-rt-users
Le 15/09/2010 00:09, Nivedita Singhvi a écrit :
> On 09/14/2010 10:38 AM, Gregory Haskins wrote:
>
>>> No. Preempt rt it's not hard realtime.
>>
>> This is not technically correct, but a common misconception. "Hard"
>> vs "Soft" is a property of the _application_, not the os/platform
>> itself, and it's based on how tolerant a given application is to
>> missed deadlines.
>>
>> "Hard" might be something like professional lossless audio, nuclear
>> fuel-rod control, bomb-squad robotics, tele-medicine, etc, where the
>> result of a missed deadline can have a serious/unacceptable negative
>> impact (death, injury, SLA failure, etc). "Soft" might be telecom
>> audio, high-frequency financial trading, etc, where misses (crappy
>> audio quality, missed market opportunity, etc) are certainly not
>> desired, but can technically be gracefully recovered from.
>>
>> Any given platform (os and hardware combo) will have quantifiable
>> performance/latency characteristics. If those characteristics exceed
>> the requirements of your application, they it would generally work to
>> run a "hard rt" application on that platform. If those
>> characteristics<= your app, it probably will not meet your deadlines
>> and therefore, a hard-rt app will fail.
>>
>> Consider a fictious nuclear fuel rod control applications with
>> requirements for a period of 20s, 500ms dutycycle, and with +- 1s
>> jitter tolerance. Failure means reactor meltdown (this is
>> hard-realtime) yet preempt-rt could certainly handle this. Heck,
>> mainline linux could probably handle this. On the other hand, if
>> anyone out there plans on doing fuel-rod control with software,
>> please tell me so I can leave the continent. ;) But the point is,
>> it's a hard-realtime application and it can be done even with
>> preempt-rt. As you scale the applicaiton's requirements tighter and
>> tighter, you will eventually find the limits of the platform to which
>> it is no longer acceptable to run the application. On modern x86
>> desktops, these limits are in the order of 10us-150us.
>>
>> The biggest challenge is _proving_ that a given platform actually
>> possesses the desired performance characteristics. This is
>> especially difficult with preempt-rt given that its based on a
>> general purpose OS (linux) and a large one that that. Smaller, more
>> RT specific os designs may be easier to prove every path has a
>> maximum latency of "X". That said, there are very few products out
>> there that could probably fit that description and most will have
>> trouble proving beyond a shadow of doubt. In addition, the
>> preempt-rt community is very responsive and treats every latency
>> source as a "bug" to be fixed/improved.
>>
>> So bottom line, if in doubt, I suggest you give preempt-rt a try.
>> Linux in general boasts probably the broadest support profile of any
>> platform out there. In addition, it's configuration is so finely
>> grained that you can probably scale it back to a lean, mean,
>> low-latency environment that will do what you need for perhaps all
>> but the most stringent requirements. Where it wouldn't work, perhaps
>> only dedicated hardware may help anyway.
>
>
Hi Nivedita;
> I would go further and say people need to stop using the terms
> "hard" and "soft". There isn't a binary yes/no answer to the real-time
> requirements spectrum.
>
I don't agree with that.
We are all OK to say that the application or the process to control
fixes the timing constraints to the overall HW/SW system.
If the application can NEVER miss an event or a deadline because it will
be catastrophic, we MUST use a hard RTOS.
If the application supports to miss (from time to time) an event or a
deadline without catastrophic consequence, we can use a soft RTOS (or a
hard RTOS if we want).
Not thinking hard nor soft realtime can have dramatic consequences.
Until now, PREEMPT-RT is a nice solution as soft RTOS and offers no
guaranty on an very big latency appeared in a particular case. Thinking
that PREEMPT-RT is a hard RTOS is false.
> Applications can have varying response time requirements, from
> microseconds to milliseconds to seconds to minutes as Greg says above.
>
> Applications might have differing penalties for missed deadlines:
> * nuclear reactor explodes
> * I lose a trade and it costs me money
> * I get a slightly different stock price quoted to me
> * Justin Bieber sounds a little hoarse
>
> If you're discussing Linux real-time, chances are your application
> does not fall in the first one. Typically a very custom engineered
> solution (hardware and software) is used for those who have rather
> severe constraints.
>
> The concept of "hard" as being mathematically/logically provable
> in terms of specs and code examination is nice, but not very practical.
> As other people have pointed out frequently, given any system, it's
> possible to break its guaranteed deadlines (catastrophic hw failure,
> etc.
You're right.
In case of possible HW failure, HW design has HW redundancies.
This discussion is very interesting but as I said in my first response,
it will be the troll for many years...
Cheers;
Patrice
>
> The real-time Linux patchset (CONFIG_PREEMPT_RT) provides real-time
> support in Linux. As you might expect from a general-purpose OS
> providing real-time, it's providing increased determinism and better
> control over your system (most significantly, your kernel tasks).
>
> A more preemptive kernel and system with better time granularity
> provides better real-time response compared to a standard kernel.
>
> It's important to note that we're not providing guarantees. Latency
> response time expectations are really based on empirical evidence,
> testing with common hw/sw/configurations and debugging issues when
> an issue is reported.
>
> Seriously, the terms "hard" and "soft" really only serve to either
> confuse or have little value (other than "custom" and "non-custom").
>
> thanks,
> Nivedita
>
>
>
> --
> 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
>
--
Patrice Kadionik. F6KQH / F4CUQ
-----------
+----------------------------------------------------------------------+
+"Tout doit etre aussi simple que possible, pas seulement plus simple" +
+----------------------------------------------------------------------+
+ Patrice Kadionik http://www.enseirb-matmeca.fr/~kadionik +
+ IMS Laboratory http://www.ims-bordeaux.fr/ +
+ ENSEIRB-MATMECA http://www.enseirb-matmeca.fr +
+ PO BOX 99 fax : +33 5.56.37.20.23 +
+ 33402 TALENCE Cedex voice : +33 5.56.84.23.47 +
+ FRANCE mailto:patrice.kadionik@ims-bordeaux.fr +
+----------------------------------------------------------------------+
--
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
^ permalink raw reply [flat|nested] 66+ messages in thread[parent not found: <4C90CF71.2050205@us.ibm.com>]
* Re: preempt rt in commercial use
[not found] ` <4C90CF71.2050205@us.ibm.com>
@ 2010-09-15 13:56 ` Patrice Kadionik
0 siblings, 0 replies; 66+ messages in thread
From: Patrice Kadionik @ 2010-09-15 13:56 UTC (permalink / raw)
To: Nivedita Singhvi; +Cc: linux-rt-users
Le 15/09/2010 15:51, Nivedita Singhvi a écrit :
> Patrice Kadionik wrote:
>
>
>> Hi Nivedita;
>>> I would go further and say people need to stop using the terms
>>> "hard" and "soft". There isn't a binary yes/no answer to the real-time
>>> requirements spectrum.
>>>
>> I don't agree with that.
>> We are all OK to say that the application or the process to control
>> fixes the timing constraints to the overall HW/SW system.
>>
>> If the application can NEVER miss an event or a deadline because it
>> will be catastrophic, we MUST use a hard RTOS.
>> If the application supports to miss (from time to time) an event or a
>> deadline without catastrophic consequence, we can use a soft RTOS (or
>> a hard RTOS if we want).
>
> No, not really. The consequences may not be catastrophic, but people
> still want performance, latency, determinism, etc. For the majority
> of applications out there, this is true. And they have specific
> requirements. So they _do_ need to ask, specifically, "can your OS
> do this?".
>
>
>> Not thinking hard nor soft realtime can have dramatic consequences.
>
> I think you missed my point. That's sort of exactly what I'm saying:
oops,
Sorry. I've misunderstood.
Cheers,
Patrice
>
> That customers/users need to think *VERY CAREFULLY* about their
> _specific_ requirements.
>
> i.e., it is never enough to ask "Is it a hard RTOS or soft"?
>
> If you have any specific requirements, the question needs to be:
>
> "can it do xxx in yyy when running zzz in ppp" etc.
>
> Followed by a whole heap of actual testing.
>
> i.e., the answer you get to the first question provides little
> value if you don't know how it is being defined, or worse, it's
> silently being defined differently than what you define it to be.
>
>
>> Until now, PREEMPT-RT is a nice solution as soft RTOS and offers no
>> guaranty on an very big latency appeared in a particular case.
>> Thinking that PREEMPT-RT is a hard RTOS is false.
>
> I'm not sure what this means, because most people I know are
> not making any kind of specific claims about PREEMPT_RT.
>
> thanks,
> Nivedita
>
--
Patrice Kadionik. F6KQH / F4CUQ
-----------
+----------------------------------------------------------------------+
+"Tout doit etre aussi simple que possible, pas seulement plus simple" +
+----------------------------------------------------------------------+
+ Patrice Kadionik http://www.enseirb.fr/~kadionik +
+ IMS Laboratory http://www.ims-bordeaux.fr/ +
+ ENSEIRB http://www.enseirb.fr +
+ PO BOX 99 fax : +33 5.56.37.20.23 +
+ 33402 TALENCE Cedex voice : +33 5.56.84.23.47 +
+ FRANCE mailto:patrice.kadionik@ims-bordeaux.fr +
+----------------------------------------------------------------------+
--
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
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: preempt rt in commercial use
2010-09-15 6:22 ` Patrice Kadionik
[not found] ` <4C90CF71.2050205@us.ibm.com>
@ 2010-09-15 14:08 ` Steven Rostedt
1 sibling, 0 replies; 66+ messages in thread
From: Steven Rostedt @ 2010-09-15 14:08 UTC (permalink / raw)
To: Patrice Kadionik; +Cc: linux-rt-users
On Wed, 2010-09-15 at 08:22 +0200, Patrice Kadionik wrote:
> Le 15/09/2010 00:09, Nivedita Singhvi a écrit :
> Hi Nivedita;
> > I would go further and say people need to stop using the terms
> > "hard" and "soft". There isn't a binary yes/no answer to the real-time
> > requirements spectrum.
> >
> I don't agree with that.
> We are all OK to say that the application or the process to control
> fixes the timing constraints to the overall HW/SW system.
>
> If the application can NEVER miss an event or a deadline because it will
> be catastrophic, we MUST use a hard RTOS.
And you also need to have a hard RT HW, which x86 is far from that. If
you have a system that can cause a catastrophic disaster on failure, you
better not be running it on a normal x86 processor.
Hence, if you don't have a proven RT HW system, you don't need to worry
about the software either.
> If the application supports to miss (from time to time) an event or a
> deadline without catastrophic consequence, we can use a soft RTOS (or a
> hard RTOS if we want).
> Not thinking hard nor soft realtime can have dramatic consequences.
>
> Until now, PREEMPT-RT is a nice solution as soft RTOS and offers no
> guaranty on an very big latency appeared in a particular case. Thinking
> that PREEMPT-RT is a hard RTOS is false.
Again, it depends on what you think hard is. If a failure wont kill
people but you will lose a million dollars, PREEMPT-RT may be good
enough. (although, if you lose a million dollars, you may still be
killed ;-)
> > Applications can have varying response time requirements, from
> > microseconds to milliseconds to seconds to minutes as Greg says above.
> >
> > Applications might have differing penalties for missed deadlines:
> > * nuclear reactor explodes
> > * I lose a trade and it costs me money
> > * I get a slightly different stock price quoted to me
> > * Justin Bieber sounds a little hoarse
> >
> > If you're discussing Linux real-time, chances are your application
> > does not fall in the first one. Typically a very custom engineered
> > solution (hardware and software) is used for those who have rather
> > severe constraints.
> >
> > The concept of "hard" as being mathematically/logically provable
> > in terms of specs and code examination is nice, but not very practical.
> > As other people have pointed out frequently, given any system, it's
> > possible to break its guaranteed deadlines (catastrophic hw failure,
> > etc.
> You're right.
> In case of possible HW failure, HW design has HW redundancies.
>
> This discussion is very interesting but as I said in my first response,
> it will be the troll for many years...
Here's what I've come up with (and presented this in Brazil last year).
True hard real time is mathematically proven software that has all known
worse case scenarios defined.
True soft real time allows for a missed deadline (as long as it is not
the norm), and the system does not fail.
PREEMPT-RT is neither of the above. What I call PREEMPT-RT is a hard
real time design. That is, we design PREEMPT-RT to be a hard real time
system but we do not mathematically prove that it is (too big to ever do
that).
But if we find a situation that a worse case scenario exists that is
over a threshold for the given hardware, we consider it a bug and it
must be fixed. A soft real time system does not consider that a bug.
So is PREEMPT-RT hard real time? No.
Is it soft real time? No.
It is in between. The design goal of PREEMPT-RT is to be hard real time,
but we will never prove that it is. Hence, when it comes to non life
threatening things but things that are very important (may lose lots of
money, but no one dies), PREEMPT-RT may very well be the product of
choice.
-- 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
^ permalink raw reply [flat|nested] 66+ messages in thread