PREEMPT_RT patch vs RTAI/Xenomai

PREEMPT_RT patch vs RTAI/Xenomai

[Asier Tamayo]

Hello all:

I'm just a newbie to this list, so just forgive me if my question is obvious or has been answered many times ;-)

I want to do a port from an old system running a proprietary RTOS to a new one based in Linux. My system runs many applications at the same time (GUI, parsers, ...), a few of which are hard real-time. 

I've searched the web, but am still unable to decide which system to use: RTAI, Xenomai or the PREEMPT_RT patch. Can anyone give me some clue in this issue? Are there any advantages in choosing the PREEMPT_RT patches over Xenomai or RTAI? Running the GUI, which demands a lot of CPU and RAM, can have any effect on the real-time behaviour?

I've seen many comparisons, but in this fast-changing world, most of them seem to me to be quite out of date.

Any hint will be really helpful,

Best regards,

Asier

Re: PREEMPT_RT patch vs RTAI/Xenomai

[Nivedita Singhvi]

Asier Tamayo wrote:
> Hello all:
> 
> I'm just a newbie to this list, so just forgive me if my question is obvious or has been answered many times ;-)
> 
> I want to do a port from an old system running a proprietary RTOS to a new one based in Linux. My system runs many applications at the same time (GUI, parsers, ...), a few of which are hard real-time. 
> 
> I've searched the web, but am still unable to decide which system to use: RTAI, Xenomai or the PREEMPT_RT patch. Can anyone give me some clue in this issue? Are there any advantages in choosing the PREEMPT_RT patches over Xenomai or RTAI? Running the GUI, which demands a lot of CPU and RAM, can have any effect on the real-time behaviour?
> 
> I've seen many comparisons, but in this fast-changing world, most of them seem to me to be quite out of date.
> 
> Any hint will be really helpful,

What are your criteria?  Do you care about anything other
than performance (availability, upgrades, cost, support,
compatibility, tools, ...)?

If your most important criteria is how well your applications
perform (whatever that means for you), you're best off testing
the solutions that you can get hold of with your own workload,
in your own environment.

Also, fwiw, there are 2 enterprise distros (Red Hat's MRG
and Novell's SLERT) providing real-time (both based on the
Linux RT patchset).

thanks,
Nivedita

RE: PREEMPT_RT patch vs RTAI/Xenomai

[Asier Tamayo]

Hello Nivedita,

Thanks for your answer.

> What are your criteria?  Do you care about anything other
> than performance (availability, upgrades, cost, support,
> compatibility, tools, ...)?
> 
> (...) you're best off testing the solutions that you can 
> get hold of with your own workload, in your own environment.
> 
Performance is a must. Besides, costs and tools are very important. Support is also important, but I guess I'd find some good support for any of the solutions.

My new CPU has an Intel Atom N270 @1.6 GHz processor. At the moment (during the porting it might be optimized), I have 5 drivers requering hard real-time (no loop can be skipped) and being called every 2 to 10 ms. In fact, at the beginning I was using 1 ms, but I had some problems with the hard real-time and changed the timing to 2 ms. I do not consider using a legacy OS emulation.

I know my final decission will have to be made after some real tests on my own system, but at this moment I'm trying to gather as much information as I can, regarding the pros and cons of each solution.

> Also, fwiw, there are 2 enterprise distros (Red Hat's MRG
> and Novell's SLERT) providing real-time (both based on the
> Linux RT patchset).
> 
Thank you very much. I'll have a look at them.

Best regards,

Asier.



> -----Original Message-----
> From: Nivedita Singhvi [mailto:niv@us.ibm.com]
> Sent: Tuesday, May 11, 2010 5:21 PM
> To: Asier Tamayo
> Cc: linux-rt-users@vger.kernel.org
> Subject: Re: PREEMPT_RT patch vs RTAI/Xenomai
> 
> 
> Asier Tamayo wrote:
> > Hello all:
> > 
> > I'm just a newbie to this list, so just forgive me if my 
> question is obvious or has been answered many times ;-)
> > 
> > I want to do a port from an old system running a 
> proprietary RTOS to a new one based in Linux. My system runs 
> many applications at the same time (GUI, parsers, ...), a few 
> of which are hard real-time. 
> > 
> > I've searched the web, but am still unable to decide which 
> system to use: RTAI, Xenomai or the PREEMPT_RT patch. Can 
> anyone give me some clue in this issue? Are there any 
> advantages in choosing the PREEMPT_RT patches over Xenomai or 
> RTAI? Running the GUI, which demands a lot of CPU and RAM, 
> can have any effect on the real-time behaviour?
> > 
> > I've seen many comparisons, but in this fast-changing 
> world, most of them seem to me to be quite out of date.
> > 
> > Any hint will be really helpful,
> 
> What are your criteria?  Do you care about anything other
> than performance (availability, upgrades, cost, support,
> compatibility, tools, ...)?
> 
> If your most important criteria is how well your applications
> perform (whatever that means for you), you're best off testing
> the solutions that you can get hold of with your own workload,
> in your own environment.
> 
> Also, fwiw, there are 2 enterprise distros (Red Hat's MRG
> and Novell's SLERT) providing real-time (both based on the
> Linux RT patchset).
> 
> thanks,
> Nivedita
> 

RE: PREEMPT_RT patch vs RTAI/Xenomai

[Steven Rostedt]

On Tue, 2010-05-11 at 17:30 +0200, Asier Tamayo wrote:
> Hello Nivedita,
> 
> Thanks for your answer.
> 
> > What are your criteria?  Do you care about anything other
> > than performance (availability, upgrades, cost, support,
> > compatibility, tools, ...)?
> > 
> > (...) you're best off testing the solutions that you can 
> > get hold of with your own workload, in your own environment.
> > 
> Performance is a must. Besides, costs and tools are very important.
> Support is also important, but I guess I'd find some good support for
> any of the solutions.
> 
> My new CPU has an Intel Atom N270 @1.6 GHz processor. At the moment
> (during the porting it might be optimized), I have 5 drivers requering
> hard real-time (no loop can be skipped) and being called every 2 to 10
> ms. In fact, at the beginning I was using 1 ms, but I had some
> problems with the hard real-time and changed the timing to 2 ms. I do
> not consider using a legacy OS emulation.

If tuned properly, PREEMPT_RT can easily handle 1ms requirements. On a
standard x86 CPU (we support others than x86) our goal is never to be
over 100us in reaction time.


> 
> I know my final decission will have to be made after some real tests
> on my own system, but at this moment I'm trying to gather as much
> information as I can, regarding the pros and cons of each solution.

One of the main benefits with running PREEMPT_RT is that any app that
works on PREEMPT_RT also works on standard Linux. No special syscalls
are needed. Which also means you can debug on any Linux box and then
test on the PREEMP_RT box.

-- Steve

Re: PREEMPT_RT patch vs RTAI/Xenomai

[Nivedita Singhvi]

Armin Steinhoff wrote:

>> If tuned properly, PREEMPT_RT can easily handle 1ms requirements. On a
>> standard x86 CPU (we support others than x86) our goal is never to be
>>   
> 
> I did a test with user space based CAN driver.
> Already the standard distribution of SUSE 11.2 (non RT) was able to 
> handle 1000 frames per seconds sent by a QNX6 machine !!

If your requirements are "never to exceed" a certain latency,
I highly recommend you run tests for long-durations, rather
than a short period. A 10-min or even a 1 hour run will not
give you a full idea as a 24-72 hour run will.

> The PREEMPT_RT version of SUSE 11.2 is much, much faster :-)
>> over 100us in reaction time.
>>   
> 
> The latency test of PREEMPT_RT shows a latency of ~10us for a dual-core 
> box at 1.8GHz.

Are you using cyclictest? And how long did you run it for?


thanks,
Nivedita

Re: PREEMPT_RT patch vs RTAI/Xenomai

[Armin Steinhoff]

Steven Rostedt wrote:
> On Tue, 2010-05-11 at 17:30 +0200, Asier Tamayo wrote:
>   
>> Hello Nivedita,
>>
>> Thanks for your answer.
>>
>>     
>>> What are your criteria?  Do you care about anything other
>>> than performance (availability, upgrades, cost, support,
>>> compatibility, tools, ...)?
>>>
>>> (...) you're best off testing the solutions that you can 
>>> get hold of with your own workload, in your own environment.
>>>
>>>       
>> Performance is a must. Besides, costs and tools are very important.
>> Support is also important, but I guess I'd find some good support for
>> any of the solutions.
>>
>> My new CPU has an Intel Atom N270 @1.6 GHz processor. At the moment
>> (during the porting it might be optimized), I have 5 drivers requering
>> hard real-time (no loop can be skipped) and being called every 2 to 10
>> ms. In fact, at the beginning I was using 1 ms, but I had some
>> problems with the hard real-time and changed the timing to 2 ms. I do
>> not consider using a legacy OS emulation.
>>     
>
> If tuned properly, PREEMPT_RT can easily handle 1ms requirements. On a
> standard x86 CPU (we support others than x86) our goal is never to be
>   

I did a test with user space based CAN driver.
Already the standard distribution of SUSE 11.2 (non RT) was able to 
handle 1000 frames per seconds sent by a QNX6 machine !!

The PREEMPT_RT version of SUSE 11.2 is much, much faster :-)
> over 100us in reaction time.
>   

The latency test of PREEMPT_RT shows a latency of ~10us for a dual-core 
box at 1.8GHz.

--Armin

http://www.steinhoff-automation.com

Re: PREEMPT_RT patch vs RTAI/Xenomai

[Armin Steinhoff]

Nivedita Singhvi wrote:
> Armin Steinhoff wrote:
>
>>> If tuned properly, PREEMPT_RT can easily handle 1ms requirements. On a
>>> standard x86 CPU (we support others than x86) our goal is never to be
>>>   
>>
>> I did a test with user space based CAN driver.
>> Already the standard distribution of SUSE 11.2 (non RT) was able to 
>> handle 1000 frames per seconds sent by a QNX6 machine !!
>
> If your requirements are "never to exceed" a certain latency,
> I highly recommend you run tests for long-durations, rather
> than a short period. A 10-min or even a 1 hour run will not
> give you a full idea as a 24-72 hour run will.

The test was running for more than 12 hours. That's the typical test 
before the software will be released.

>
>> The PREEMPT_RT version of SUSE 11.2 is much, much faster :-)
>>> over 100us in reaction time.
>>>   
>>
>> The latency test of PREEMPT_RT shows a latency of ~10us for a 
>> dual-core box at 1.8GHz.
>
> Are you using cyclictest? And how long did you run it for?

Several hours ...

--Armin

PS: my initial post has been posted again because of internet problems, 
sorry.

Re: PREEMPT_RT patch vs RTAI/Xenomai

[Robert Schwebel]

On Thu, May 13, 2010 at 10:01:12AM +0200, Armin Steinhoff wrote:
> I did a test with user space based CAN driver.

The Linux CAN interface is SocketCAN. Do you see a usecase where this
doesn't fit?

> Already the standard distribution of SUSE 11.2 (non RT) was able to
> handle 1000 frames per seconds sent by a QNX6 machine !!

Realtime != fast.

> The latency test of PREEMPT_RT shows a latency of ~10us for a
> dual-core box at 1.8GHz.

It depends on the load.

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 patch vs RTAI/Xenomai

[Armin Steinhoff]

Robert Schwebel wrote:
> On Thu, May 13, 2010 at 10:01:12AM +0200, Armin Steinhoff wrote:
>   
>> I did a test with user space based CAN driver.
>>     
> The Linux CAN interface is SocketCAN. Do you see a usecase where this
> doesn't fit?
>   

IMHO, the SocketCAN interface is simply an overkill for the handling of
small CAN messages.
I estimate that the  amount of executed code for handling of a single
CAN frame is much bigger as the frame itself :)
Every read and write action creates context switches ...

This is not the case with the user space based driver.  Same story with
our PROFIBUS-DP drivers ...

>> Already the standard distribution of SUSE 11.2 (non RT) was able to
>> handle 1000 frames per seconds sent by a QNX6 machine !!
>>     
>
> Realtime != fast.
>   

But a small response time is a technological requirement in order to
meet deadlines.
The standard kernel is a _good base_ in order to implement predictive
behavior ... this would not the case if the response time would be in
the range of 100us.
OK ... you can have real-time behavior with a response time of 100us ..
but this would be useless for most real-time applications.

>> The latency test of PREEMPT_RT shows a latency of ~10us for a
>> dual-core box at 1.8GHz.
>>     
>
> It depends on the load.
>   

It depends on the load and the used priorities.

--Armin

Re: PREEMPT_RT patch vs RTAI/Xenomai

[Robert Schwebel]

On Fri, May 14, 2010 at 11:34:47AM +0200, Armin Steinhoff wrote:
> > The Linux CAN interface is SocketCAN. Do you see a usecase where
> > this doesn't fit?
>
> IMHO, the SocketCAN interface is simply an overkill for the handling
> of small CAN messages. I estimate that the amount of executed code
> for handling of a single CAN frame is much bigger as the frame itself
> :) Every read and write action creates context switches ...
>
> This is not the case with the user space based driver. Same story
> with our PROFIBUS-DP drivers ...

Do you see a use case which shows that a reasonably modern CPU has
performance problems with SocketCAN, while it works fine with your
userspace driver? My impression from previous projects is that, for all
real life scenarios, the advantage of having a standard hardware
abstraction in the kernel overwhelms a few microseconds here and there
on the performance side.

> > > Already the standard distribution of SUSE 11.2 (non RT) was able
> > > to handle 1000 frames per seconds sent by a QNX6 machine!!
> >
> > Realtime != fast.
>
> But a small response time is a technological requirement in order to
> meet deadlines. The standard kernel is a _good base_ in order to
> implement predictive behavior ... this would not the case if the
> response time would be in the range of 100us. OK ... you can have
> real-time behavior with a response time of 100us .. but this would be
> useless for most real-time applications.

Above you state that you send "1000 frames per second", but that has
nothing to do with response times. Sending lots of frames works also if
you have for example a CAN chip with a long FIFO, push the frames in and
wait forever. "Repsonse time" does involve some kind of round trip,
which one do you mean? Can you elaborate where you see the need for us
response times?

As the minimum reaction time is limited by hardware constraints on
modern cpus anyway, I think that for most applications which require sub
100 us response times, a hardware solution (microcontroller, fpga) is a
better way to achive things.

>>> The latency test of PREEMPT_RT shows a latency of ~10us for a
>>> dual-core box at 1.8GHz.
>>
>> It depends on the load.
>
> It depends on the load and the used priorities.

For a given application, with predefined priorities, it depends on the
load :-)

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 patch vs RTAI/Xenomai

[Armin Steinhoff]

Robert Schwebel wrote:
> On Fri, May 14, 2010 at 11:34:47AM +0200, Armin Steinhoff wrote:
>   
>>> The Linux CAN interface is SocketCAN. Do you see a usecase where
>>> this doesn't fit?
>>>       
>> IMHO, the SocketCAN interface is simply an overkill for the handling
>> of small CAN messages. I estimate that the amount of executed code
>> for handling of a single CAN frame is much bigger as the frame itself
>> :) Every read and write action creates context switches ...
>>
>> This is not the case with the user space based driver. Same story
>> with our PROFIBUS-DP drivers ...
>>     
>
> Do you see a use case which shows that a reasonably modern CPU has
> performance problems with SocketCAN, while it works fine with your
> userspace driver? My impression from previous projects is that, for all
> real life scenarios, the advantage of having a standard hardware
> abstraction in the kernel 

How many "hardware abstractions" do you want in the kernel ?

>>> Realtime != fast.
>>>       
>> But a small response time is a technological requirement in order to
>> meet deadlines. The standard kernel is a _good base_ in order to
>> implement predictive behavior ... this would not the case if the
>> response time would be in the range of 100us. OK ... you can have
>> real-time behavior with a response time of 100us .. but this would be
>> useless for most real-time applications.
>>     
>
> Above you state that you send "1000 frames per second", but that has
> nothing to do with response times. 

The response time of the whole real-time application 
(hardware/driver/application) is the point.
If Linux wouldn't able to handle every 100us a CAN frame ... the whole 
real-time application would be useless.

> Sending lots of frames works also if
> you have for example a CAN chip with a long FIFO, push the frames in and
> wait forever.

But every so called "long FIFO" is limited and can reach the overun state.

>  "Repsonse time" does involve some kind of round trip,
> which one do you mean? 

Responses of an real-time application to external events ...

> Can you elaborate where you see the need for us
> response times?
>
> As the minimum reaction time is limited by hardware constraints on
> modern cpus anyway, I think that for most applications which require sub
> 100 us response times, a hardware solution (microcontroller, fpga) is a
> better way to achive things.
>   

Why should we use FPGAs when a CPU has multiple cores ?
Every fast fieldbus ( e.g. EtherCAT) needs a reaction time with less 
than 100us.

--Armin

---
Armin Steinhoff   <as@Steinhoff-Automation.com> 
STEINHOFF Automation &  Fieldbus-Systems
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TEL +49-6431 -529366  or  -570 99 70
FAX +49-6431 - 57454  or  -570 99 80
http://www.steinhoff-automation.com

Re: PREEMPT_RT patch vs RTAI/Xenomai

[Armin Steinhoff]

Robert Schwebel wrote:
> On Fri, May 14, 2010 at 02:32:22PM +0200, Armin Steinhoff wrote:
>   
>>> Do you see a use case which shows that a reasonably modern CPU has
>>> performance problems with SocketCAN, while it works fine with your
>>> userspace driver? My impression from previous projects is that, for
>>> all real life scenarios, the advantage of having a standard hardware
>>> abstraction in the kernel
>>>       
>> How many "hardware abstractions" do you want in the kernel?
>>     
>
> The kernel policy is to offer only one abstraction model for one sort of
> hardware; SocketCAN is a native Linux implementation and has no
> additional HAL.
>   

And how many different kinds of hardware do we have ??

>> The response time of the whole real-time application
>> (hardware/driver/application) is the point. If Linux wouldn't able to
>> handle every 100us a CAN frame ... the whole real-time application
>> would be useless.
>>     
>
> I still don't understand your setup, can you elaborate?
>   

When you send every 100us a CAN frame  and the response time of the 
real-time application to external  events is 200us ... what would be 
happen ?  Hard to understand ??

>>> Sending lots of frames works also if you have for example a CAN chip
>>> with a long FIFO, push the frames in and wait forever.
>>>       
>> But every so called "long FIFO" is limited and can reach the overun
>> state.
>>     
>
> My point is to find out where you see a relation to "latency". Latency
> has nothing to do with CAN frames per second. 

I never did such a statement ... you are barking on the wrong tree :)

> If you have a FIFO which
> is long enough, feeding it every let's say 1 second with 1k messages is
> enough to get 1k messages/s. So a system latency of 1 s would fulfill
> your throughput requirements.
>   

Well ... and if the latency to receive events is too high (e.g. 2s) ... 
the FIFO  will be overloaded.
That was my initial statement ...

>> Why should we use FPGAs when a CPU has multiple cores? Every fast
>> fieldbus (e.g. EtherCAT) needs a reaction time with less than 100us.
>>     
>
> Reaction time between *which events*? Sorry, I didn't understand your
> use case yet.
>   

Never heard about bus scan cycles ?  In a range of  e.g. 50us ?
Such bus cycles can't be handled with a latency of 100us  ...  isn't it  ?

Cheers

--Armin

PS:  so langsam  wird die Diskussion  nun doch ein wenig albern  ...

Re: PREEMPT_RT patch vs RTAI/Xenomai

[Robert Schwebel]

On Fri, May 14, 2010 at 02:32:22PM +0200, Armin Steinhoff wrote:
> > Do you see a use case which shows that a reasonably modern CPU has
> > performance problems with SocketCAN, while it works fine with your
> > userspace driver? My impression from previous projects is that, for
> > all real life scenarios, the advantage of having a standard hardware
> > abstraction in the kernel
>
> How many "hardware abstractions" do you want in the kernel?

The kernel policy is to offer only one abstraction model for one sort of
hardware; SocketCAN is a native Linux implementation and has no
additional HAL.

> The response time of the whole real-time application
> (hardware/driver/application) is the point. If Linux wouldn't able to
> handle every 100us a CAN frame ... the whole real-time application
> would be useless.

I still don't understand your setup, can you elaborate?

> > Sending lots of frames works also if you have for example a CAN chip
> > with a long FIFO, push the frames in and wait forever.
>
> But every so called "long FIFO" is limited and can reach the overun
> state.

My point is to find out where you see a relation to "latency". Latency
has nothing to do with CAN frames per second. If you have a FIFO which
is long enough, feeding it every let's say 1 second with 1k messages is
enough to get 1k messages/s. So a system latency of 1 s would fulfill
your throughput requirements.

> > "Repsonse time" does involve some kind of round trip, which one do
> > you mean?
>
> Responses of an real-time application to external events ...
>
> > Can you elaborate where you see the need for us response times?
> >
> > As the minimum reaction time is limited by hardware constraints on
> > modern cpus anyway, I think that for most applications which require
> > sub 100 us response times, a hardware solution (microcontroller,
> > fpga) is a better way to achive things.
>
> Why should we use FPGAs when a CPU has multiple cores? Every fast
> fieldbus (e.g. EtherCAT) needs a reaction time with less than 100us.

Reaction time between *which events*? Sorry, I didn't understand your
use case yet.

Thanks,
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 patch vs RTAI/Xenomai

[Robert Schwebel]

On Fri, May 14, 2010 at 06:29:41PM +0200, Armin Steinhoff wrote:
> > The kernel policy is to offer only one abstraction model for one
> > sort of hardware; SocketCAN is a native Linux implementation and has
> > no additional HAL.
>
> And how many different kinds of hardware do we have??

I've re-read the whole thread, and I must say that I don't understand
what you want to explain. What do you mean with "kinds of hardware"?
Talking about CAN, do you mean different CAN controllers? Or do you mean
different device classes, like in "can", "ethernet", ...?

> When you send every 100us a CAN frame and the response time of the
> real-time application to external events is 200us ... what would be
> happen? Hard to understand ??

I assume that with "send" you mean "receive", right? As long as you
don't have a closed loop scenario, nothing bad happens:

        ---------------  ------------------
        |  canframe   |  |   canframe     |
        |  received   |  |   processed    |
        | by hardware |  | by application |
        ---------------  ------------------
              |                   |
  0 us   canframe-1               |
              |                   |
100 us   canframe-2               |
              |                   |
200 us   canframe-3          canframe-1
              |                   |
300 us   canframe-4          canframe-2
              |                   |
400 us   canframe-5          canframe-3
              |                   |

If you FIFO is long enough, no frame gets lost. The driver might even
load canframe-1..3 out of the hardware at 200 us and push it forward.

Latencies do only hurt if you have a closed loop, i.e. if you want to
run a control program with a 100 us cycle:

        ---------------  ------------------ ---------------
        |  canframe   |  |                | |  canframe   |
        |  received   |  |   application  | |    sent     |
        | by hardware |  |                | | by hardware |
        ---------------  ------------------ ---------------
              |                   |               |
  0 us   canframe-1               |               |
              |            recv-canframe-1        |
              |             do-something          |
              |            send-canframe-2        |
              |                   |          canframe-2
              |                   |               |
100 us   canframe-3               |               |
              |            recv-canframe-3        |
              |             do-something          |
              |            send-canframe-4        |
              |                   |          canframe-4
              |                   |               |

I guess that's what you mean?

You answered "1000s of canframes per second" to a latency question.
"canframes per second" correlates to throughput, not response time.

> > > Why should we use FPGAs when a CPU has multiple cores? Every fast
> > > fieldbus (e.g. EtherCAT) needs a reaction time with less than
> > > 100us.
> >
> > Reaction time between *which events*? Sorry, I didn't understand
> > your use case yet.
>
> Never heard about bus scan cycles? In a range of e.g. 50us? Such bus
> cycles can't be handled with a latency of 100us ... isn't it?

If you need < 50 us roundtrip time than your worst case latencies have
to be lower, that's right. However, 50 us is a cycle time is close to
the lower limit of what normal processor hardware can provide. How close
depends on your actual hardware, but not even processors in the Atom
range might be able to provide this (from the hardware side) under all
operating conditions. It's a matter of how close to the limb you want to
walk. And it's not a matter of Xenomai vs. RT Preempt.

> PS: so langsam wird die Diskussion nun doch ein wenig albern ...

The original poster has requirements to run cyclic tasks every 2..10 ms,
which can be easily handled by today's hardware and by both, RT_PREEMPT
and Xenomai.

I agree that it's probably better to discuss things like CAN in
userspace, EtherCAT and cycles in the 50 us range separately (eventually
on the right lists) and with a clear statement about what the discussion
is.

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

fast interprocess communication ?

[Armin Steinhoff]

Hello,

what are you using if you need a "real fast"  interprocess communication ?

Is there a way to use the UIO approach for fast synchronous message 
passing ?

--Armin
 
PS:   real-fast means not socket based ...

Re: fast interprocess communication ?

[Pradyumna Sampath]

Hi Armin,

On Wed, Jun 30, 2010 at 1:33 PM, Armin Steinhoff <armin@steinhoff.de> wrote:

> what are you using if you need a "real fast"  interprocess communication ?

Does the posix mqueue's not fit your need ? Have you tried them ? Do
have some kind of numbers about your definition of fast ?

For me, the POSIX mqueues seemed to work, though with some initial
trouble which was fixed with a patch to the kernel follow this thread
( http://lkml.org/lkml/2010/4/2/293 ) , this patch is now queued for
mainline inclusion for 2.6.35.

There is also a new test suite to measure message queue perf in the
rt-tests. Its called pmqtest.

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: fast interprocess communication ?

[Armin Steinhoff]

Hi Prady,

Pradyumna Sampath wrote:
> Hi Armin,
>
> On Wed, Jun 30, 2010 at 1:33 PM, Armin Steinhoff <armin@steinhoff.de> wrote:
>
>   
>> what are you using if you need a "real fast"  interprocess communication ?
>>     
>
> Does the posix mqueue's not fit your need ? 

The mqueue system is based on the file system and isn't the fastest.
The concept of mqueue is OK ...

> Have you tried them ? Do
> have some kind of numbers about your definition of fast ?
>   

Local message exchange between lokal processes in less than 10us.

> For me, the POSIX mqueues seemed to work, though with some initial
> trouble which was fixed with a patch to the kernel follow this thread
> ( http://lkml.org/lkml/2010/4/2/293 ) , this patch is now queued for
> mainline inclusion for 2.6.35.
>
> There is also a new test suite to measure message queue perf in the
> rt-tests. Its called pmqtest.
>   

Interesting ... I will give it a try.

I plan do some conceptual work for a UIO based message passing solution.
It should be possible to use read and write (triggering 
uio_event_notify() ) and a UIO device memory to implement a non-copy 
data exchange.

Regards

--Armin

Re: fast interprocess communication ?

[Pradyumna Sampath]

Hi Armin,

On Mon, Jul 5, 2010 at 6:48 PM, Armin Steinhoff <armin@steinhoff.de> wrote:

> Local message exchange between lokal processes in less than 10us.

As per my measurements, mqueue meets this criteria. It was compared
with a test suite which ran against _a_popular_commercial_rtos_ and
RT_PREEMPT linux and the performance was equally good on both. Like I
said, the problem was the accuracy of the timeouts (mq_timedrecieve
and mq_timedsend) which is now fixed and mainlined.

regards
/prady

--
http://www.prady.in