On Fri, May 14, 2010 at 11:34:47AM +0200, Armin Steinhoff wrote: > > 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 ... 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 overwhelms a few microseconds here and there on the performance side. > > > 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. Above you state that you send "1000 frames per second", but that has nothing to do with response times. 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. "Repsonse time" does involve some kind of round trip, which one do you mean? 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. >>> 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. For a given application, with predefined priorities, it depends on the load :-) 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 | -- 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
