Re: preempt rt in commercial use

[Patrice Kadionik <kadionik@enseirb-matmeca.fr>]

  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