linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robert Schwebel <r.schwebel@pengutronix.de>
To: Armin Steinhoff <armin@steinhoff.de>
Cc: linux-rt-users@vger.kernel.org
Subject: Re: PREEMPT_RT patch vs RTAI/Xenomai
Date: Fri, 14 May 2010 18:36:13 +0200	[thread overview]
Message-ID: <20100514163613.GE6055@pengutronix.de> (raw)
In-Reply-To: <4BED42D6.3090303@steinhoff.de>

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 |

  reply	other threads:[~2010-05-14 16:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-11 14:42 PREEMPT_RT patch vs RTAI/Xenomai Asier Tamayo
2010-05-11 15:20 ` Nivedita Singhvi
2010-05-11 15:30   ` Asier Tamayo
2010-05-12 16:07     ` Steven Rostedt
     [not found]       ` <4BEAFB7E.90304@steinhoff.de>
2010-05-13  1:27         ` Nivedita Singhvi
2010-05-13  8:07           ` Armin Steinhoff
2010-05-13  8:01       ` Armin Steinhoff
2010-05-13 17:58         ` Robert Schwebel
2010-05-14  9:34           ` Armin Steinhoff
2010-05-14 11:46             ` Robert Schwebel
2010-05-14 12:32               ` Armin Steinhoff
2010-05-14 16:36                 ` Robert Schwebel [this message]
2010-05-14 16:29                   ` Armin Steinhoff
2010-05-14 20:53                     ` Robert Schwebel
2010-06-30 11:33               ` fast interprocess communication ? Armin Steinhoff
2010-06-30 11:39                 ` Pradyumna Sampath
2010-07-05 16:48                   ` Armin Steinhoff
2010-07-06 10:29                     ` Pradyumna Sampath

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=20100514163613.GE6055@pengutronix.de \
    --to=r.schwebel@pengutronix.de \
    --cc=armin@steinhoff.de \
    --cc=linux-rt-users@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).