Bertil Bäck wrote: >> >> The routing of CAN frames inside the kernel makes sense because of the >> missing >> copy to/from userspace and the scheduling that happens to userspace apps. >> First tests proved a low latency (about 22 usecs on my Core2Duo 2GHz) and >> especially a low jitter for the routed CAN frames. >> > Would like to try this out, but could you describe how you measured to > get 22usec? What CAN hardware did you use, how many ports you have > tested with would also be nice to know :) > > I try to use a test like the following: > /"Routing delay is measured from the last bit of an message on one port > and the first bit of the of the same message on another port. Measured @ > 1Mbps and the last frame of a 30 message back to back burst."/
Hello Bertil, so far i just made a simple measurement with the virtual CAN interfaces. My setup is: - setup vcan0 and vcan1 - set this simple 1:1 routing job: cangw -A -s vcan0 -d vcan1 -e - start on a terminal: candump -ta any - in a second terminal type : cansend vcan0 123# The result is u...@host:~$ candump -ta any (1266922451.156115) vcan0 123 [0] (1266922451.156139) vcan1 123 [0] (1266922463.923817) vcan0 123 [0] (1266922463.923837) vcan1 123 [0] (1266922467.714736) vcan0 123 [0] (1266922467.714757) vcan1 123 [0] which is something around 20 usecs. In both cases (vcan0/vcan1) the timestamp is set at netif_rx(). The can-gw just put's the (routed) CAN frame into the destination netdev tx-queue within the NET_RX softirq of the source netdev. See at gw_rcv() in net/can/gw.c Of course it depends on the status of the current destination tx queue how fast the routed CAN frame is send on the wire. This is not guaranteed of course. The idea of the can-gw is just to make it as fast as possible (and to get rid of the routing in userspace). Regards, Oliver _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
