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 ...
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
