Oliver Hartkopp wrote:
> 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

Hello,
thanks for explaining, will see if I can find time to test this in 
hardware. Would be interesting to see what kind of routing delay one can 
get. Some of the bigger problems I have seen is to get can controllers 
that can route messages fast. SPI attached can controllers is often a 
big bottle neck.

Br,
Bertil

_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core

Reply via email to