From: Armin Steinhoff <armin@steinhoff.de>
To: Robert Schwebel <r.schwebel@pengutronix.de>
Cc: linux-rt-users@vger.kernel.org
Subject: Re: PREEMPT_RT patch vs RTAI/Xenomai
Date: Fri, 14 May 2010 18:29:41 +0200 [thread overview]
Message-ID: <4BED7A75.9030508@steinhoff.de> (raw)
In-Reply-To: <20100514163613.GE6055@pengutronix.de>
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 ...
next prev parent reply other threads:[~2010-05-14 17:18 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
2010-05-14 16:29 ` Armin Steinhoff [this message]
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=4BED7A75.9030508@steinhoff.de \
--to=armin@steinhoff.de \
--cc=linux-rt-users@vger.kernel.org \
--cc=r.schwebel@pengutronix.de \
/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).