Re: [Xenomai-help] How to chose between xenomai and preempt RT

Re: [Xenomai-help] How to chose between xenomai and preempt RT

[Adrien LECOINTRE]

Jeff Angielski wrote:
> Of course, just by choosing to use Xenomai, you don't get hard realtime. 
>   You still need to design your system and software correctly.

Yes but a software can be well designed on PREEMPT_RT as well.
I built a kernel and a filesystem with the less possible number of driver. After startup there is only an ATA driver and bash running on my system! In this situation I really doubt that a big latency can occurs.

Then if my real-time software uses a specific device I just have to write my own driver (instead of using a "basic" linux driver) if I want to know exactly what's going on my system and keep a hard real-time behavior.

Those are basics things that we always do when designing a real-time software on any RT OS.

Of course for a real-time software with a lot of non-real-time loads it's probably easier to use Xenomai and let Linux deals with loads.

I read a lot of things about PREEMPT_RT not providing hard real-time but I coudn't find any test case which shows that. My loads are probably not good enough but it shouldn't be so difficult to find a way to cause a significant latency on a supposed non-hard-real-time OS.

Adrien.

Re: [Xenomai-help] How to chose between xenomai and preempt RT

[Gilles Chanteperdrix]

Adrien LECOINTRE wrote:
> Jeff Angielski wrote:
>> Of course, just by choosing to use Xenomai, you don't get hard
>> realtime. You still need to design your system and software
>> correctly.
> 
> Yes but a software can be well designed on PREEMPT_RT as well. I
> built a kernel and a filesystem with the less possible number of
> driver. After startup there is only an ATA driver and bash running on
> my system! In this situation I really doubt that a big latency can
> occurs.

Modern ATA means DMA, which means contention with the real-time system,
whatever this system is. So, large disk transfers will cause big latencies.

> 
> Then if my real-time software uses a specific device I just have to
> write my own driver (instead of using a "basic" linux driver) if I
> want to know exactly what's going on my system and keep a hard
> real-time behavior.

I would say the drivers need auditing and maybe to be modified, not to
be rewritten. Rewriting them is probably a waste of time, and you do not
benefit from using PREEMPT_RT if you do that.

> 
> Those are basics things that we always do when designing a real-time
> software on any RT OS.
> 
> Of course for a real-time software with a lot of non-real-time loads
> it's probably easier to use Xenomai and let Linux deals with loads.
> 
> I read a lot of things about PREEMPT_RT not providing hard real-time
> but I coudn't find any test case which shows that. My loads are
> probably not good enough but it shouldn't be so difficult to find a
> way to cause a significant latency on a supposed non-hard-real-time
> OS.

You are really talking in the void as long as you do not tell us what
platform you intend to use.

-- 
					    Gilles.

Re: [Xenomai-help] How to chose between xenomai and preempt RT

[Gilles Chanteperdrix]

Gilles Chanteperdrix wrote:
> Adrien LECOINTRE wrote:
>> Jeff Angielski wrote:
>>> Of course, just by choosing to use Xenomai, you don't get hard
>>> realtime. You still need to design your system and software
>>> correctly.
>> Yes but a software can be well designed on PREEMPT_RT as well. I
>> built a kernel and a filesystem with the less possible number of
>> driver. After startup there is only an ATA driver and bash running on
>> my system! In this situation I really doubt that a big latency can
>> occurs.
> 
> Modern ATA means DMA, which means contention with the real-time system,
> whatever this system is. So, large disk transfers will cause big latencies.
> 
>> Then if my real-time software uses a specific device I just have to
>> write my own driver (instead of using a "basic" linux driver) if I
>> want to know exactly what's going on my system and keep a hard
>> real-time behavior.
> 
> I would say the drivers need auditing and maybe to be modified, not to
> be rewritten. Rewriting them is probably a waste of time, and you do not
> benefit from using PREEMPT_RT if you do that.

The minimal modification that you want to do to make a driver real-time
with preempt_rt is to make its irqs non threaded and make its spinlocks
good old raw spinlocks.

-- 
					    Gilles.

Re: [Xenomai-help] How to chose between xenomai and preempt RT

[Gilles Chanteperdrix]

Adrien LECOINTRE wrote:
> I read a lot of things about PREEMPT_RT not providing hard real-time
> but I coudn't find any test case which shows that. My loads are
> probably not good enough but it shouldn't be so difficult to find a
> way to cause a significant latency on a supposed non-hard-real-time
> OS.

I can not leave this unanswered. This is a question of code coverage.
Only when you have tested most of the code paths in the Linux kernel can
you state that you have made a proper test. The only way to do this
found so far (by the preempt_rt people, I believe) is to run LTP, the
Linux Testing Project. And even though you do not test all the drivers
in your system (except the most current ones such as ethernet and ATA).

-- 
					    Gilles.

[Xenomai-help] How to chose between xenomai and preempt RT

[Adrien LECOINTRE]

Hi,

I've been testing for a while, Xenomai and Linux preempt RT latencies 
under different loads and I couldn't find any big differences. Latencies 
are almost the same.
So my question is, do you know any case where Xenomai is really better 
than a simple preempt RT?
Or which specification in a real time application should make me chose 
Xenomai instead of preempt RT?

Thanks

Re: [Xenomai-help] How to chose between xenomai and preempt RT

[Jeff Angielski]

Adrien LECOINTRE wrote:
> Hi,
> 
> I've been testing for a while, Xenomai and Linux preempt RT latencies 
> under different loads and I couldn't find any big differences. Latencies 
> are almost the same.
> So my question is, do you know any case where Xenomai is really better 
> than a simple preempt RT?
> Or which specification in a real time application should make me chose 
> Xenomai instead of preempt RT?

I suspect your loads are not sufficiently exercising your system.

To answer your question, though, it all depends on your requirements, 
whether you need hard or soft realtime.  In other words, is it ok to 
miss your deadline every so often?  If so, CONFIG_PREEMPT would be fine 
for you. If you can't miss any deadlines, use Xenomai.

Of course, just by choosing to use Xenomai, you don't get hard realtime. 
  You still need to design your system and software correctly.

As time marches on, the CONFIG_PREEMPT is getting closer to hard 
realtime, especially with the interrupt threading, but I don't think 
that time is now.

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

Re: [Xenomai-help] How to chose between xenomai and preempt RT

[Gilles Chanteperdrix]

Jeff Angielski wrote:
> Adrien LECOINTRE wrote:
>> Hi,
>>
>> I've been testing for a while, Xenomai and Linux preempt RT latencies 
>> under different loads and I couldn't find any big differences. Latencies 
>> are almost the same.
>> So my question is, do you know any case where Xenomai is really better 
>> than a simple preempt RT?
>> Or which specification in a real time application should make me chose 
>> Xenomai instead of preempt RT?
> 
> I suspect your loads are not sufficiently exercising your system.
> 
> To answer your question, though, it all depends on your requirements, 
> whether you need hard or soft realtime.  In other words, is it ok to 
> miss your deadline every so often?  If so, CONFIG_PREEMPT would be fine 
> for you. If you can't miss any deadlines, use Xenomai.
> 
> Of course, just by choosing to use Xenomai, you don't get hard realtime. 
>   You still need to design your system and software correctly.
> 
> As time marches on, the CONFIG_PREEMPT is getting closer to hard 
> realtime, especially with the interrupt threading, but I don't think 
> that time is now.

threaded interrupts are no silver bullet, they are essentially replacing
interrupt latencies with kernel-space scheduling latencies; on x86, this
may not make that much of a difference, but on low-end platform it does.

See also:
https://mail.gna.org/public/xenomai-help/2008-05/msg00043.html
https://mail.gna.org/public/xenomai-help/2009-06/msg00005.html

-- 
					    Gilles.

Re: [Xenomai-help] How to chose between xenomai and preempt RT

[Jeff Angielski]

Gilles Chanteperdrix wrote:
>>
>> As time marches on, the CONFIG_PREEMPT is getting closer to hard 
>> realtime, especially with the interrupt threading, but I don't think 
>> that time is now.
> 
> threaded interrupts are no silver bullet, they are essentially replacing
> interrupt latencies with kernel-space scheduling latencies; on x86, this
> may not make that much of a difference, but on low-end platform it does.
> 
> See also:
> https://mail.gna.org/public/xenomai-help/2008-05/msg00043.html
> https://mail.gna.org/public/xenomai-help/2009-06/msg00005.html

I meant to write PREEMPT_RT is getting closer to hard realtime.  Sorry 
for the confusion.

As for the interrupt threads, the advantage is not in the latency, it is 
in the ability to control the scheduling of the handlers.  In theory, 
you can schedule your handler the have the highest priority handler.

I totally agree on the different real life performance on the low end 
platforms vs the x86 desktops.

In the end, I think this is a good discussion to have [and keep up to 
date] since it bring out the fundamental design choices of doing 
realtime using Linux.

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

Re: [Xenomai-help] How to chose between xenomai and preempt RT

[Gilles Chanteperdrix]

Jeff Angielski wrote:
> Gilles Chanteperdrix wrote:
>>> As time marches on, the CONFIG_PREEMPT is getting closer to hard 
>>> realtime, especially with the interrupt threading, but I don't think 
>>> that time is now.
>> threaded interrupts are no silver bullet, they are essentially replacing
>> interrupt latencies with kernel-space scheduling latencies; on x86, this
>> may not make that much of a difference, but on low-end platform it does.
>>
>> See also:
>> https://mail.gna.org/public/xenomai-help/2008-05/msg00043.html
>> https://mail.gna.org/public/xenomai-help/2009-06/msg00005.html
> 
> I meant to write PREEMPT_RT is getting closer to hard realtime.  Sorry 
> for the confusion.
> 
> As for the interrupt threads, the advantage is not in the latency, it is 
> in the ability to control the scheduling of the handlers.  In theory, 
> you can schedule your handler the have the highest priority handler.

The real advantage or the threaded interrupts is that the part of the
kernel-space code that need to protect from a particular interrupt
remains preemptible by other interrupts. The interrupt handler
themselves were already preemptible, if they did not use the
IRQF_DISABLED flag.

Note that the same effect could be obtained by disabling only the
particular interrupt at PIC level, but this would have mean a lot more
of code changes than what threaded interrupts need. But probably a lot
less run-time overhead.

-- 
					    Gilles.

Re: [Xenomai-help] How to chose between xenomai and preempt RT

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]

Jeff Angielski wrote:
> Adrien LECOINTRE wrote:
>> Hi,
>>
>> I've been testing for a while, Xenomai and Linux preempt RT latencies 
>> under different loads and I couldn't find any big differences. Latencies 
>> are almost the same.
>> So my question is, do you know any case where Xenomai is really better 
>> than a simple preempt RT?
>> Or which specification in a real time application should make me chose 
>> Xenomai instead of preempt RT?
> 
> I suspect your loads are not sufficiently exercising your system.

I may. But the question is also if the test is sufficiently close to the
final RT use case. One may think that running cyclictest alone gives the
full picture of -rt's determinism, but it only stresses one simple use
case of the kernel.

> 
> To answer your question, though, it all depends on your requirements, 
> whether you need hard or soft realtime.  In other words, is it ok to 
> miss your deadline every so often?  If so, CONFIG_PREEMPT would be fine 
> for you. If you can't miss any deadlines, use Xenomai.
> 
> Of course, just by choosing to use Xenomai, you don't get hard realtime. 
>   You still need to design your system and software correctly.
> 
> As time marches on, the CONFIG_PREEMPT is getting closer to hard 
> realtime, especially with the interrupt threading, but I don't think 
> that time is now.
> 

Theoretically, -rt/CONFIG_PREEMPT_RT can provide this already - if you
do not hit implementation problems with the particular use case, or the
application uses services which do not provide real-time qualities on -rt.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]