All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: Rudolf Meijering <rudolf@domain.hid>
Cc: Jan Kiszka <jan.kiszka@domain.hid>,
	"xenomai@xenomai.org" <xenomai@xenomai.org>
Subject: Re: [Xenomai-help] RT OS Selection advice for parallel processing
Date: Fri, 04 Feb 2011 23:15:52 +0100	[thread overview]
Message-ID: <4D4C7A98.1030104@domain.hid> (raw)
In-Reply-To: <AANLkTimdawDBCnZon1v06F6uFf1dqwt8Re11rXPv6ZnY@mail.gmail.com>

Rudolf Meijering wrote:
> Thanks a lot for everyone's input! It seems like for our application, GPU
> off-loading is not the way to go. We have redesigned our system for all
> processing to take place on the Intel i7. Total maximum processing latency
> stays 100ms, and interrupt frequency goes up to 1.5 KHz.
> 
> I have done some research on the pro's and con's of PREEMPT_RT vs Xenomai.
> As far as I can determine some of the benefits include:
> 1. Programming with Xenomai native API's are more elegant than POSIX
> real-time API’s.
> 2. Xenomai has possibly less overhead than a full preemptive kernel. The
> user interface does not require RT capabilities.
> 
> Are there any other substantial benefits worth considering? Which would you
> use?

Another factor, is that with Xenomai, the application needs a clear
separation between real-time and non real-time tasks. They do not use
the same services, they need to interact through special means. This is
a double edged sword:
- on one edge, with this clear separation, you have no doubt about which
code will be deterministic and which will not be;
- on the other edge, you end up using two APIS for interacting with two
different schedulers, which complicates things a bit.

-- 
                                                                Gilles.



  reply	other threads:[~2011-02-04 22:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-03  8:57 [Xenomai-help] RT OS Selection advice for parallel processing Rudolf Meijering
2011-02-03 10:35 ` Jan Kiszka
2011-02-03 11:04   ` Gilles Chanteperdrix
2011-02-03 11:24     ` Jan Kiszka
2011-02-03 11:27       ` Gilles Chanteperdrix
2011-02-03 11:46         ` Jan Kiszka
2011-02-03 11:49           ` Gilles Chanteperdrix
2011-02-03 12:50             ` Jan Kiszka
2011-02-03 13:21               ` Gilles Chanteperdrix
2011-02-04 13:33                 ` Rudolf Meijering
2011-02-04 22:15                   ` Gilles Chanteperdrix [this message]
2011-02-12 18:13                   ` Richard Cochran

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=4D4C7A98.1030104@domain.hid \
    --to=gilles.chanteperdrix@xenomai.org \
    --cc=jan.kiszka@domain.hid \
    --cc=rudolf@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.