From: Jan Kiszka <jan.kiszka@domain.hid>
To: Asier Tamayo <asier.tamayo@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] Xenomai and/or PREEMPT_RT patch
Date: Tue, 11 May 2010 16:05:28 +0200 [thread overview]
Message-ID: <4BE96428.4080104@domain.hid> (raw)
In-Reply-To: <DFFBF4EB468A894AB1474ED220F05AF60134C0BA@srv-dc.ona-electroerosion.com>
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 seen there are many approaches to the real-time issue in Linux; finally, it seems to me that the only solutions that will last are Xenomai and the PREEMPT_RT patches (OSADL). Am I wrong?
These are surely the primary candidates. More approaches exists, but I
wouldn't start considering them until you reach the limits of the
mentioned ones (which is quite hard these days).
>
> Can anybody give me some advice about which system to use? Any good comparison I can read? Everything I find comparing real-time Linux approaches seems to be quite out of date.
There are many factors of your scenario that influence a comparison. So
you should sketch your requirements and variables first. To name a few:
- CPU architecture
- overview on your critical loop(s)
- their timing requirements
- portability of your applications (to decide about application
adaption vs. legacy OS emulation)
As we are on the Xenomai list, the major strengths (personal opinion) of
this approach should already be mentioned:
- well extensible to emulate legacy RTOS APIs
- strict separation between RT and Linux domain - nevertheless, both
contexts are smoothly usable from within the very same user space
application
> Should I use Xenomai on its own? Or maybe Xenomai and Linux with the preempt patches applied? Running the GUI, which demands a lot of CPU and RAM, can have any effect on the real-time behaviour?
Independent of the software approach, hardware can always ruin your day,
specifically on x86 (SMI, contentions on I/O buses, shared caches,
etc.). Weather this matters to you, depends on your timing requirements
and how "hard" your real-time has to be.
>
> Any hint will be really helpful,
>
> Best regards,
>
> Asier
HTH,
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2010-05-11 14:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-11 6:05 [Xenomai-help] Xenomai and/or PREEMPT_RT patch Asier Tamayo
2010-05-11 14:05 ` Jan Kiszka [this message]
2010-05-11 14:32 ` Asier Tamayo
2010-05-11 16:01 ` Jan Kiszka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BE96428.4080104@domain.hid \
--to=jan.kiszka@domain.hid \
--cc=asier.tamayo@domain.hid \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.