Robert Schwebel wrote:
On Thu, May 13, 2010 at 10:01:12AM +0200, Armin Steinhoff wrote:
I did a test with user space based CAN driver.
The Linux CAN interface is SocketCAN. Do you see a usecase where this
doesn't fit?
IMHO, the SocketCAN interface is simply an overkill for the handling of
small CAN messages.
I estimate that the amount of executed code for handling of a single
CAN frame is much bigger as the frame itself :)
Every read and write action creates context switches ...
This is not the case with the user space based driver. Same story with
our PROFIBUS-DP drivers ...
Already the standard distribution of SUSE 11.2 (non RT) was able to
handle 1000 frames per seconds sent by a QNX6 machine !!
Realtime != fast.
But a small response time is a technological requirement in order to
meet deadlines.
The standard kernel is a _good base_ in order to implement predictive
behavior ... this would not the case if the response time would be in
the range of 100us.
OK ... you can have real-time behavior with a response time of 100us ..
but this would be useless for most real-time applications.
The latency test of PREEMPT_RT shows a latency of ~10us for a
dual-core box at 1.8GHz.
It depends on the load.
It depends on the load and the used priorities.
--Armin
--
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
