preempt rt in commercial use

preempt rt in commercial use

[Raz]

Hello
some companies asked me to show that premmpt rt is comercially used.
are you using it ?
Thank you
raz

Re: preempt rt in commercial use

[Rolando Martins]

Hi,
RedHat uses it in their enterprise "real-time" distribution.
I work in a portuguese Telecom/Transportation company (www.efacec.pt)
that will use the preempt patch.

Rolando

On Tue, Sep 14, 2010 at 9:10 AM, Raz <raziebe@gmail.com> wrote:
> Hello
> some companies asked me to show that premmpt rt is comercially used.
> are you using it ?
> Thank you
> raz
> --
> 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
>
--
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

Re: preempt rt in commercial use

[Raz]

first thank you.
I am trying to push preempt rt (conferences and consulting ) and i am
collecting information that can help other companies to do this big
step and move from vx to linux.
Rolando, is your system hard real time or soft rt ?

Thank you

On Tue, Sep 14, 2010 at 11:04 AM, Rolando Martins
<rolando.martins@gmail.com> wrote:
> Hi,
> RedHat uses it in their enterprise "real-time" distribution.
> I work in a portuguese Telecom/Transportation company (www.efacec.pt)
> that will use the preempt patch.
>
> Rolando
>
> On Tue, Sep 14, 2010 at 9:10 AM, Raz <raziebe@gmail.com> wrote:
>> Hello
>> some companies asked me to show that premmpt rt is comercially used.
>> are you using it ?
>> Thank you
>> raz
>> --
>> 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
>>
>
--
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

Re: preempt rt in commercial use

[Rolando Martins]

;)
It's soft rt.

On Tue, Sep 14, 2010 at 10:10 AM, Raz <raziebe@gmail.com> wrote:
> first thank you.
> I am trying to push preempt rt (conferences and consulting ) and i am
> collecting information that can help other companies to do this big
> step and move from vx to linux.
> Rolando, is your system hard real time or soft rt ?
>
> Thank you
>
> On Tue, Sep 14, 2010 at 11:04 AM, Rolando Martins
> <rolando.martins@gmail.com> wrote:
>> Hi,
>> RedHat uses it in their enterprise "real-time" distribution.
>> I work in a portuguese Telecom/Transportation company (www.efacec.pt)
>> that will use the preempt patch.
>>
>> Rolando
>>
>> On Tue, Sep 14, 2010 at 9:10 AM, Raz <raziebe@gmail.com> wrote:
>>> Hello
>>> some companies asked me to show that premmpt rt is comercially used.
>>> are you using it ?
>>> Thank you
>>> raz
>>> --
>>> 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
>>>
>>
>
--
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

Re: preempt rt in commercial use

[Nikita V. Youshchenko]

> Hello
> some companies asked me to show that premmpt rt is comercially used.
> are you using it ?

MontaVista has long supplied preempt-rt to lots of it's customers.

Re: preempt rt in commercial use

[Raz]

anyone can say preempt rt is hard real time ?
anyone knows preempt rt known bugs ?
why is it not mainline yet ?

thank you
raz

On Tue, Sep 14, 2010 at 11:17 AM, Nikita V. Youshchenko <yoush@cs.msu.su> wrote:
>> Hello
>> some companies asked me to show that premmpt rt is comercially used.
>> are you using it ?
>
> MontaVista has long supplied preempt-rt to lots of it's customers.
>

Re: preempt rt in commercial use

[Robert Schwebel]

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.

> anyone knows preempt rt known bugs?

Like every software or every technical system it of course has bugs.

> why is it not mainline yet?

Large parts of the original patches are in the Linux mainline in the
mean time, and the rest is constantly being worked on, in order to bring
them into the official kernel as well.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: preempt rt in commercial use

[Armin Steinhoff]

  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.
>
Hm, and what do think about that statement from FSMLabs:

"Linux “PREEMPT” real-time is a continuing experiment aimed at audio
and video playing with unreliable results and a detrimental affect on
“enterprise” performance"

--Armin


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

Re: preempt rt in commercial use

[Daniel James]

Hi Armin,

> Hm, and what do think about that statement from FSMLabs:
> 
> "Linux “PREEMPT” real-time is a continuing experiment aimed at audio
> and video playing with unreliable results and a detrimental affect on
> “enterprise” performance"

I believe that quote comes from a sales pitch for RTLinux:

http://www.yodaiken.com/papers/preempt.pdf

In that context, it's hardly likely to be objective criticism :-)

Cheers!

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

Re: preempt rt in commercial use

[Pradyumna Sampath]

Hi,

On Tue, Sep 14, 2010 at 2:16 PM, Armin Steinhoff <armin@steinhoff.de> wrote:
> Hm, and what do think about that statement from FSMLabs:
>
> "Linux “PREEMPT” real-time is a continuing experiment aimed at audio
> and video playing with unreliable results and a detrimental affect on
> “enterprise” performance"

I guess the US Navy DDG 1000 Zumwalt Class Destroyer Program (now
cancelled) is not enterpise enough ?

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

Re: preempt rt in commercial use

[Nivedita Singhvi]

On 09/14/2010 06:08 AM, Pradyumna Sampath wrote:
> Hi,
>
> On Tue, Sep 14, 2010 at 2:16 PM, Armin Steinhoff<armin@steinhoff.de>  wrote:
>> Hm, and what do think about that statement from FSMLabs:
>>
>> "Linux “PREEMPT” real-time is a continuing experiment aimed at audio
>> and video playing with unreliable results and a detrimental affect on
>> “enterprise” performance"
>
> I guess the US Navy DDG 1000 Zumwalt Class Destroyer Program (now
> cancelled) is not enterpise enough ?

This program is not cancelled in its entirety -- much of it is
most assuredly in place and continuing to proceed as planned.

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

Re: preempt rt in commercial use

[Klaas van Gend]

On Tuesday 14 September 2010 14:16:38 Armin Steinhoff wrote:
> Hm, and what do think about that statement from FSMLabs:
> 
> "Linux “PREEMPT” real-time is a continuing experiment aimed at audio
> and video playing with unreliable results and a detrimental affect on
> “enterprise” performance"

Someone trying to sell his own solution.

Of course Yodaiken was not going to tell "yeah, that other solution is good 
enough".

-- 
Klaas van Gend
Senior Solutions Architect, MontaVista Software LLC

phone: +31 40 2801386
--
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

Re: preempt rt in commercial use

[David Kastrup]

Armin Steinhoff <armin@steinhoff.de> writes:

>  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.
>>
> Hm, and what do think about that statement from FSMLabs:
>
> "Linux “PREEMPT” real-time is a continuing experiment aimed at audio
> and video playing with unreliable results and a detrimental affect on
> “enterprise” performance"

Kernel preemption is a complex thing.  Letting the kernel be a
low-priority realtime task (which is what most "enterprise" solutions do
instead) still preempts the kernel, though only with realtime tasks, not
competing tasks.  Treating the kernel as a black box does not give you
finer-grained control over device drivers etc unless you move the device
drivers into the realtime realm.

When a failure to service a device in a given time frame will result in
hardware damage, you don't want a system as complex as the whole kernel
involved.  A realtime control system around that is more secure, but a
dedicated, physically separate controller for meeting the hard
constraints might be the safer choice.

-- 
David Kastrup

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

RE: preempt rt in commercial use

[Darcy Watkins]

I have used RT preemption to ensure that WiMAX radio PHY and MAC drivers
can be appropriately prioritized to avoid hardware I/O overun and
underrun conditions.

Like some have mentioned, trying to maintain this essential stability
simultaneous with high throughput (especially high bandwidth stream of
really small packets) can still be a challenge.

Regards,

Darcy

Re: preempt rt in commercial use

[Patrice Kadionik]

  Le 14/09/2010 14:16, Armin Steinhoff a écrit :
>  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.
>>
> Hm, and what do think about that statement from FSMLabs:
>
> "Linux “PREEMPT” real-time is a continuing experiment aimed at audio
> and video playing with unreliable results and a detrimental affect on
> “enterprise” performance"
Hello,

"soft realtime vs hard realtime" will be the troll in the embedded 
community for the next years after the "with or without MMU" troll...


Patrice
>
> --Armin
>
>
> -- 
> 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 Kadionikhttp://www.enseirb.fr/~kadionik          +
+ IMS Laboratoryhttp://www.ims-bordeaux.fr/              +
+ ENSEIRBhttp://www.enseirb.fr                    +
+ PO BOX 99                    fax   : +33 5.56.37.20.23               +
+ 33402 TALENCE Cedex          voice : +33 5.56.84.23.47               +
+ FRANCEmailto: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

Re: preempt rt in commercial use

[Jeff Angielski]

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.

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.

-- 
Jeff Angielski
The PTR Group
www.theptrgroup.com

Re: preempt rt in commercial use

[Nikita V. Youshchenko]

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

Re: preempt rt in commercial use

[Jeff Angielski]

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

Re: preempt rt in commercial use

[Nivedita Singhvi]

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

Re: preempt rt in commercial use

[Armin Steinhoff]

  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
>

Re: preempt rt in commercial use

[Nivedita Singhvi]

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

Re: preempt rt in commercial use

[Pradyumna Sampath]

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

Re: preempt rt in commercial use

[Daniel James]

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

Re: preempt rt in commercial use

[Pradyumna Sampath]

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

Re: preempt rt in commercial use

[Raz]

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
>

Re: preempt rt in commercial use

[David Kastrup]

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

Re: preempt rt in commercial use

[Nivedita Singhvi]

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

Re: preempt rt in commercial use

[David Kastrup]

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

Re: preempt rt in commercial use

[Steven Rostedt]

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

Re: preempt rt in commercial use

[Nivedita Singhvi]

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

Re: preempt rt in commercial use

[Steven Rostedt]

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

Re: preempt rt in commercial use

[Armin Steinhoff]

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
>

Re: preempt rt in commercial use

[Steven Rostedt]

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

Re: preempt rt in commercial use

[Thomas Gleixner]

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

Re: preempt rt in commercial use

[Pradyumna Sampath]

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

Re: preempt rt in commercial use

[Sergio Ruocco]

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

Re: preempt rt in commercial use

[Pradyumna Sampath]

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

Re: preempt rt in commercial use

[Paul E. McKenney]

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

Re: preempt rt in commercial use

[Sven-Thorsten Dietrich]

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

Re: preempt rt in commercial use

[Steven Rostedt]

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

Re: preempt rt in commercial use

[David Kastrup]

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

Re: preempt rt in commercial use

[Armin Steinhoff]

  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

Re: preempt rt in commercial use

[Patrice Kadionik]

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

Re: preempt rt in commercial use

[Gregory Haskins]

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

Re: preempt rt in commercial use

[Nivedita Singhvi]

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

Re: preempt rt in commercial use

[Patrice Kadionik]

  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

Re: preempt rt in commercial use

[Patrice Kadionik]

  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

Re: preempt rt in commercial use

[Steven Rostedt]

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

Re: preempt rt in commercial use

[Klaas van Gend]

On Tuesday 14 September 2010 11:17:12 Nikita V. Youshchenko wrote:
> > Hello
> > some companies asked me to show that premmpt rt is comercially used.
> > are you using it ?
> 
> MontaVista has long supplied preempt-rt to lots of it's customers.

Let me elaborate on that a little.

Yes, we have a *lot* of customers using PREEMPT_RT. 
In my experience they fall into a few different categories:

1) using it because "it is faster". Well, I've tried to squash that idea at 
every customer I've been, but it's not easy to get out of their heads. 
In most cases, these customers have no clue why they enabled it.

2) using it because Linux was too slow otherwise.
Unfortunately something I've run across a few times now - that the embedded 
boards are too slow to reliably grab all bytes from a serial port. 
Of course this has something to do with system load and bad design of serial 
data streams... In many cases, missing a byte can cause serious trouble, like 
having to do a whole sample analysis again (lab equipment). 

3) using it to work around system limitations, e.g. reducing priority on less 
relevant interrupts and/or threads.
This is the best use case. For example, if you design data acquisition or 
control loops, they better run reliably, with low jitter. So you want to 
reduce priority of everything not that relevant.


Hope this helps!


-- 
Klaas van Gend
Senior Solutions Architect, MontaVista Software LLC

phone: +31 40 2801386

Re: preempt rt in commercial use

[David Kastrup]

Klaas van Gend <klaas.van.gend@mvista.com> writes:

> On Tuesday 14 September 2010 11:17:12 Nikita V. Youshchenko wrote:
>> > Hello
>> > some companies asked me to show that premmpt rt is comercially used.
>> > are you using it ?
>> 
>> MontaVista has long supplied preempt-rt to lots of it's customers.
>
> Let me elaborate on that a little.
>
> Yes, we have a *lot* of customers using PREEMPT_RT. 
> In my experience they fall into a few different categories:
>
> 1) using it because "it is faster". Well, I've tried to squash that
> idea at every customer I've been, but it's not easy to get out of
> their heads.  In most cases, these customers have no clue why they
> enabled it.
>
> 2) using it because Linux was too slow otherwise.
> Unfortunately something I've run across a few times now - that the embedded 
> boards are too slow to reliably grab all bytes from a serial port. 
> Of course this has something to do with system load and bad design of serial 
> data streams... In many cases, missing a byte can cause serious trouble, like 
> having to do a whole sample analysis again (lab equipment).

This is rather important for audio applications.  You can't afford a
single missed sample in hour-long sessions.

> 3) using it to work around system limitations, e.g. reducing priority on less 
> relevant interrupts and/or threads.
> This is the best use case. For example, if you design data acquisition or 
> control loops, they better run reliably, with low jitter. So you want to 
> reduce priority of everything not that relevant.

I don't call that "working around".  A computer is supposed to do what
it is told to do.  When there are priorities, you need to tell them to
the computer rather than expect that it should somehow figure them out
itself.

-- 
David Kastrup

Re: preempt rt in commercial use

[Pradyumna Sampath]

Hi,

On Tue, Sep 14, 2010 at 10:10 AM, Raz <raziebe@gmail.com> wrote:
> Hello
> some companies asked me to show that premmpt rt is comercially used.
> are you using it ?

This is a very interesting question which I always wonder and have
always wanted to know. Many companies even if they are using might not
want to tell in a public forum like this. But I know of some companies
that use it, there are some papers out there detailing some research
work in this area by companies.

best regards
/prady

-- 
http://www.prady.in

Re: preempt rt in commercial use

[Reagan Thomas]

  On 9/14/2010 3:10 AM, Raz wrote:
> Hello
> some companies asked me to show that premmpt rt is comercially used.
> are you using it ?
> Thank you
> raz
> -- 

[We] use it in radar video distribution to ensure IO deadlines.

AW: preempt rt in commercial use

[Lukas Redlinger]

  On 9/14/2010 3:10 AM, Raz wrote:
> Hello
> some companies asked me to show that premmpt rt is comercially used.
> are you using it ?
> Thank you
> raz
> -- 

We use it for our "realtime" local position measurement system (LPM) to
stay in sync with some hardware components. Nothing critical, but if we
miss one cycle (1ms) we have to completely stop the measurement and
start over

Re: preempt rt in commercial use

[jordan]

Hi Raz,

> Hello
> some companies asked me to show that premmpt rt is comercially used.
> are you using it ?

A big one would be the TSE (Tokyo Stock Exchange).  "Arrowhead" is
built on RedHat Enterprise, and is a "hard real-time" system.  I have
a feeling that a lot of the financial sector (in the US/canada/europe)
are using rt-linux.

Next, in the Pro-audio sector, you have Muse Research who make the
"Recepter".  Which is a hardware VST host. It was developed so Artists
could use the same sounds/plugins produced in the studio live.
All of the big names in the music industry use them live, and/or in
the studio. as they are very robust, and reliable.
(you can't have your sound skipping, when your playing in front of
thousands of people).

Then there is "CableCam", which is an Rt-linux based high-flying
Camera. Used in Professional Sports heavily, and equally, if not more
so, by the Film Industry...

Which leads me to my last example. Most people are aware that since
about 1999-2000, Linux has dominated the movie industry. Beginning
with Titanic and even today with say, Avatar.

I would be willing to bet, that all of those wonderful rendering farms
and production suites, are
in fact using rt-linux.

Beyond that, IBM, Intel, Novell, FSMLabs, Oracle, RedHat.....

I hope that helps, there is a lot of info available around the
interweb. Lots of papers, by companies on the subject. and lots of
case examples of usage.

Jordan

Re: preempt rt in commercial use

[Klaas van Gend]

On Wednesday 15 September 2010 05:38:49 jordan wrote:
>
> Which leads me to my last example. Most people are aware that since
> about 1999-2000, Linux has dominated the movie industry. Beginning
> with Titanic and even today with say, Avatar.
> 
> I would be willing to bet, that all of those wonderful rendering farms
> and production suites, are
> in fact using rt-linux.


Please put a lot of money on that bet, because I'd like to win it :-)

Why would those rendering farms use rt-linux?

Rendering is not done in real-time - far from it actually. It can take minutes 
of the entire farm to render a single frame. So rendering is nothing but CPU-
intensive (calculating how all those lightbeams are reflected by each surface) 
- and everything I/O bound is about throughput: writing the rendered pixels to 
disk and getting more surfaces from disk.

There are no deadlines for rendering, there are no penalties if a frame is 
late by seconds - if the farm cannot complete its job overnight, they'll add 
more CPU power.


-- 
Klaas van Gend
Senior Solutions Architect, MontaVista Software LLC

phone: +31 40 2801386

TinxCore and PREEMPT_RT

[Armin Steinhoff]

Hi all,

are there any experiences in using the TinyCore distribution as a base 
for PREEMPT_RT Linux ?

Patching a PREEMPT_RT kernel (2.6.29.6) with the TinyCore patch 2.6.29.1 
seems to work ... no error messages so far.


--Armin

Re: TinxCore and PREEMPT_RT

[Armin Steinhoff]

Hi all,

yes, it's running !

TinyCore is very small (10MB) , works with the PREEMPT_RT patch (at 
least version 2.6.29.6), full SMP support and boots in few seconds!
The MicroCore version needs only 6MB ...

--Armin




Armin Steinhoff wrote:
>
> Hi all,
>
> are there any experiences in using the TinyCore distribution as a base 
> for PREEMPT_RT Linux ?
>
> Patching a PREEMPT_RT kernel (2.6.29.6) with the TinyCore patch 
> 2.6.29.1 seems to work ... no error messages so far.
>
>
> --Armin
>
> -- 
> 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
>

Re: TinxCore and PREEMPT_RT

[David Kastrup]

Armin Steinhoff <armin@steinhoff.de> writes:

> Hi all,
>
> yes, it's running !
>
> TinyCore is very small (10MB) , works with the PREEMPT_RT patch (at
> least version 2.6.29.6), full SMP support and boots in few seconds!
> The MicroCore version needs only 6MB ...

Anybody else nostalgic about the times where it took around 10kB to host
a realtime multi-tasking operating system including self-hosting target
compiler?

And the challenge was to fit bootstrap loader and operating system on
one track of the floppy disk?

Heck, the first UNIXes I used regularly were quite workable with 4MB of
main memory.

I'll go back hide under my rock again.  Thanks for listening.

-- 
David Kastrup

Re: TinxCore and PREEMPT_RT

[Mike Galbraith]

On Thu, 2010-09-16 at 12:18 +0200, David Kastrup wrote:
> Armin Steinhoff <armin@steinhoff.de> writes:
> 
> > Hi all,
> >
> > yes, it's running !
> >
> > TinyCore is very small (10MB) , works with the PREEMPT_RT patch (at
> > least version 2.6.29.6), full SMP support and boots in few seconds!
> > The MicroCore version needs only 6MB ...
> 
> Anybody else nostalgic about the times where it took around 10kB to host
> a realtime multi-tasking operating system including self-hosting target
> compiler?
> 
> And the challenge was to fit bootstrap loader and operating system on
> one track of the floppy disk?
> 
> Heck, the first UNIXes I used regularly were quite workable with 4MB of
> main memory.

Heh, my first ram weighed ~160 lbs per 512KB, high speed/low drag 4 wire
technology, 2 us cycle time, dual or quad ported for your SMP pleasure.

(a real bargain at slightly under $1000/lb)

> I'll go back hide under my rock again.  Thanks for listening.

Ditto :)

	-Mike

Re: TinxCore and PREEMPT_RT

[Armin Steinhoff]

  David Kastrup wrote:
> Armin Steinhoff<armin@steinhoff.de>  writes:
>
>> Hi all,
>>
>> yes, it's running !
>>
>> TinyCore is very small (10MB) , works with the PREEMPT_RT patch (at
>> least version 2.6.29.6), full SMP support and boots in few seconds!
>> The MicroCore version needs only 6MB ...
> Anybody else nostalgic about the times where it took around 10kB to host
> a realtime multi-tasking operating system including self-hosting target
> compiler?
>
> And the challenge was to fit bootstrap loader and operating system on
> one track of the floppy disk?
>
> Heck, the first UNIXes I used regularly were quite workable with 4MB of
> main memory.

   I developed years ago a control system for an automatic store system 
based on Xenix 1.x and Informix for a 512kB machine.
   So 4MB seems to be very huge :)

  --Armin

   PS: TinyCore is an issue for the guys addicted to the embedded 
real-time stuff ... based on the 2.6 kernel !

Re: preempt rt in commercial use

[Nivedita Singhvi]

Klaas van Gend wrote:
> On Wednesday 15 September 2010 05:38:49 jordan wrote:
>> Which leads me to my last example. Most people are aware that since
>> about 1999-2000, Linux has dominated the movie industry. Beginning
>> with Titanic and even today with say, Avatar.
>>
>> I would be willing to bet, that all of those wonderful rendering farms
>> and production suites, are
>> in fact using rt-linux.
> 
> 
> Please put a lot of money on that bet, because I'd like to win it :-)
> 
> Why would those rendering farms use rt-linux?
> 
> Rendering is not done in real-time - far from it actually. It can take minutes 
> of the entire farm to render a single frame. So rendering is nothing but CPU-
> intensive (calculating how all those lightbeams are reflected by each surface) 
> - and everything I/O bound is about throughput: writing the rendered pixels to 
> disk and getting more surfaces from disk.
> 
> There are no deadlines for rendering, there are no penalties if a frame is 
> late by seconds - if the farm cannot complete its job overnight, they'll add 
> more CPU power.

While all of the above is true, I'll add that it's worth testing
RT because certain applications which have lock-step operations,
can be very negatively impacted in throughput by severe lack of
determinism.  If all of a set of operations need to complete before
they can do the next set of operations, and one of the threads takes
very long, the others all idle as a result. If this happens frequently,
you're better off trying to cap max latencies.

So RT actually provides improved *throughput* as well, despite the
increased overhead.

I don't know if these rendering type applications necessarily
fall into that bucket, but I would at least take a look.


thanks,
Nivedita

Re: preempt rt in commercial use

[Reagan Thomas]

  On 9/15/2010 9:03 AM, Nivedita Singhvi wrote:
> Klaas van Gend wrote:
>> On Wednesday 15 September 2010 05:38:49 jordan wrote:
>>> Which leads me to my last example. Most people are aware that since
>>> about 1999-2000, Linux has dominated the movie industry. Beginning
>>> with Titanic and even today with say, Avatar.
>>>
>>> I would be willing to bet, that all of those wonderful rendering farms
>>> and production suites, are
>>> in fact using rt-linux.
>>
>>
>> Please put a lot of money on that bet, because I'd like to win it :-)
>>
>> Why would those rendering farms use rt-linux?
>>
>> Rendering is not done in real-time - far from it actually. It can 
>> take minutes of the entire farm to render a single frame. So 
>> rendering is nothing but CPU-
>> intensive (calculating how all those lightbeams are reflected by each 
>> surface) - and everything I/O bound is about throughput: writing the 
>> rendered pixels to disk and getting more surfaces from disk.
>>
>> There are no deadlines for rendering, there are no penalties if a 
>> frame is late by seconds - if the farm cannot complete its job 
>> overnight, they'll add more CPU power.
>
> While all of the above is true, I'll add that it's worth testing
> RT because certain applications which have lock-step operations,
> can be very negatively impacted in throughput by severe lack of
> determinism.  If all of a set of operations need to complete before
> they can do the next set of operations, and one of the threads takes
> very long, the others all idle as a result. If this happens frequently,
> you're better off trying to cap max latencies.
>
> So RT actually provides improved *throughput* as well, despite the
> increased overhead.
>
> I don't know if these rendering type applications necessarily
> fall into that bucket, but I would at least take a look.
>
>
> thanks,
> Nivedita 

I haven't messed with rendering much since the Amiga days, but my 
understanding is that a given CPU could render anywhere from just a 
single pixel to entire frames independent of the work on any other 
processor.  Raw CPU, cache hits and fast memory win.  High bus/network 
bandwidth and storage sweep up the pieces. I would try to use the 
lightest kernel I could get by with, boot from network and run from RAM 
with only the services necessary to get scene info in and rendered 
pixels out.  In my mind, a render box should be single purposed with few 
competing processes. I suspect that determinism is much less important 
than efficiency here.

Then again, it may still be cheaper to "add more CPU" than to give more 
than cursory attention to the kernel or OS.  It may be the case where 
Linux or *BSD have been used in render farms because of license cost, 
not for any particular technical merit!

/ducks

-Reagan

Re: preempt rt in commercial use

[Daniel James]

Hi Reagan,

> It may be the case where
> Linux or *BSD have been used in render farms because of license cost,
> not for any particular technical merit!

No, the effects houses that adopted GNU/Linux en masse in the mid to
late 1990's have plenty of budget for OS licences. If you can afford to
build a scale model of the Titanic in an aircraft hangar, then the cost
of Windows for 200 render farm nodes is hardly noticeable.

The reason was that the studios were migrating from SGI Irix onto higher
performance, lower cost x86 hardware. GNU/Linux was familiar to the Irix
application developers and sysadmins, who did not want to migrate to
Windows.

It was about the best tools for the job, not some bogus perception that
Free Software is 'cheap' because it is given freely (which upsets the
developers I know).

There's an old interview here that provides some background:

http://tuxdeluxe.org/node/126

Cheers!

Daniel

Re: preempt rt in commercial use

[jordan]

Hey Reagan.

>> It may be the case where
>> Linux or *BSD have been used in render farms because of license cost,
>> not for any particular technical merit!

Try modifying Windows or OSX, to be as streamlined as Linux can be.
Try to make fundamental changes to
the operating system itself... You cant do that with Proprietary code.
(obviously)

> The reason was that the studios were migrating from SGI Irix onto higher
> performance, lower cost x86 hardware. GNU/Linux was familiar to the Irix
> application developers and sysadmins, who did not want to migrate to
> Windows.
>
> It was about the best tools for the job, not some bogus perception that
> Free Software is 'cheap' because it is given freely (which upsets the
> developers I know).

Daniel, is so very correct here. Even if Windows was free, they still
wouldn't be using it. For all the reasons Daniel has explained, and
the other example i have written above. Windows/OSX are not flexible
enough, for these more specific applications/usages.

jordan

Re: preempt rt in commercial use

[Daniel James]

Hi Jordan,

> Next, in the Pro-audio sector, you have Muse Research who make the
> "Recepter".  Which is a hardware VST host.

That's just one example of many in the pro audio sector (that we know
about, since the companies involved aren't required to disclose their
use of GNU/Linux - it's a competitive advantage, so they have a
disincentive to do so). Several flagship audio mixing and recording
systems use the Linux kernel, including the Harrison Xrange:

http://www.harrisonconsoles.com/joomla/index.php?option=com_content&task=view&id=26&Itemid=51

and the Midas XL8:

http://www.midasconsoles.com/xl8.php

If you have been to see a Hollywood movie, or attended a stadium gig on
a rock band's world tour, you have almost certainly been listening to
audio mixed on a Harrison or Midas console - these companies are at the
top of their game.

RT-Linux provides significant advantage for these companies over
proprietary RTOS products because of time-to-market, not licence costs:
there are many audio software components available for re-use, leaving
the integrator to write the last parts of the code.

There's also knowledge transfer from the Linux HPC sector - for example,
the Xrange uses up to 120 Opteron CPUs, so it's hardly a 'desktop'
system. You don't get that combination of high performance and reliable,
re-usable source code with any other platform, RT or otherwise.

Licence fees for proprietary software aren't the big deal for companies
selling a relatively small number of expensive products. I think people
get confused with consumer products like mobile phones, where it's
supposedly all about volume. Actually, I think the independence of OEM's
from proprietary software vendors has more to do with it. Microsoft has
significant lock-in with consumers, and yet it still can't persuade
people to buy Windows phones :-)

Cheers!

Daniel

Re: preempt rt in commercial use

[jordan]

Hey Daniel,

>> Next, in the Pro-audio sector, you have Muse Research who make the
>> "Recepter".  Which is a hardware VST host.
>
> That's just one example of many in the pro audio sector (that we know
> about, since the companies involved aren't required to disclose their
> use of GNU/Linux - it's a competitive advantage, so they have a
> disincentive to do so). Several flagship audio mixing and recording
> systems use the Linux kernel, including the Harrison Xrange:

Muse Research doesn't hide their linux usage - they advertise it, and
if you look at the demo videos, they explain quite clearly why they
use it over any other OS...  These companies should be using linux, in
my opinion. I just hope they contribute some code back to the
Open-source community, as i feel that is important. Not to give away
everything,
but hey, throw us a bone or two. ya know...?

> http://www.harrisonconsoles.com/joomla/index.php?option=com_content&task=view&id=26&Itemid=51
>
> and the Midas XL8:
>
> http://www.midasconsoles.com/xl8.php
>
> If you have been to see a Hollywood movie, or attended a stadium gig on
> a rock band's world tour, you have almost certainly been listening to
> audio mixed on a Harrison or Midas console - these companies are at the
> top of their game.

Oh crap, i should've mentioned that one. I am very aware of Harrison.
I took an audio engineering program, and also have friends in the
industry, so i have had a chance to see some of this stuff up close.
My cousin also has managed some of the biggest rock acts on the
planet, so i have been somewhat lucky. I have also taken a look at
Mixbus too.  Ya, the BBC uses Harrison...  I have no experience with
Midas(i've heard of them though),
Thanks for the link, i'll have a look.

> RT-Linux provides significant advantage for these companies over
> proprietary RTOS products because of time-to-market, not licence costs:
> there are many audio software components available for re-use, leaving
> the integrator to write the last parts of the code.

> There's also knowledge transfer from the Linux HPC sector - for example,
> the Xrange uses up to 120 Opteron CPUs, so it's hardly a 'desktop'
> system. You don't get that combination of high performance and reliable,
> re-usable source code with any other platform, RT or otherwise.

Interesting stuff. (you seem to be quite well-informed)

> Licence fees for proprietary software aren't the big deal for companies
> selling a relatively small number of expensive products. I think people
> get confused with consumer products like mobile phones, where it's
> supposedly all about volume. Actually, I think the independence of OEM's
> from proprietary software vendors has more to do with it.

I agree.

> Microsoft has significant lock-in with consumers, and yet it still can't persuade
> people to buy Windows phones :-)

Microsoft's bad business practices, and crappy software, is why no one
is loyal to them, or interested in Windows CE.
I used one, and was not impressed, neither was my friend who ditched
the phone a month later. it sucks, Especially when compared to either
Android, and obviously the iPhone.

> Cheers!

back at you!

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