Re: SJA1000 loopback feature

[Oliver Hartkopp <socketcan@hartkopp.net>]

On 19.06.2014 18:01, Alexander GQ Gerasiov wrote:
> Thu, 19 Jun 2014 16:55:40 +0200
> Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> 
>>>> Just to give an example how I dealed with such situation:
>>>>
>>>> 1. Let all applications run on a virtual CAN interface (e.g.
>>>> vcan0). 2. make a cross routing with can-gw netlink routes
>>>
>>> Yes, I was thinking about it. We strictly need the same order of
>>> events on both buses (local/virtual and remote/hardware), but in
>>> case of bridging (userspace, or even in-kernel one) race is
>>> possible. So we'd better use one bus (to rule them all =)) 
>>>
>>
>> You have a strict order on vcan0. And this order is then transfered
>> to the real can0. OTOH the order on can0 is forwarded to vcan0. Where
>> do you see a problem here?
> Correct me if I'm wrong, but if I'm quite sure, there will be the
> following problem:
> 
> Application works on vcan and initiate transmit A on time T.
> Another (hardware) node initiate transmit B on physical bus on the same
> T.

So your hosts are absolutely synchronized (via ntp)??

> 
> On vcan you will see A (on T+dt1), B (on T+dt1+dt2).

How do you get the timestamp information then?
E.g. you can configute the routing rule with '-t' option to preserve the
src_dev rx timestamp. You would see the timestamp from the real CAN tnen.

> On bus you will see B (on T+dt3), A (on T+dt3+dt4).

Hm - i wonder if you would really see a difference as the networking stack is
not real-time anyway. When sending on vcan (which has no receive queue) the rx
is performed instantly which leads to en-queue the frame into the real CAN
interface immediately.

> 
> As we develop testbench environment, the order of events our software
> see (and logs) should be the same as hardware nodes see.
> 

Looks interesting. Your experiences are welcome :-)

Regards,
Oliver