Hi, The virtual can (vcan driver) directly queues the tx messages on the rx path. As a consequence a sending program, canseq e.g. is only cpu limited and as a consequence the network stack can start dropping messages. For a realistic applications, it takes a bit more time to realize the network stack is actually dropping message, since the cpu doesn't necessarily go to 100%, it can just burst just enough to cause some messages to be dropped, causing unexpected behavior. The vcan driver behavior can be altered with e.g.: sudo tc qdisc add dev vcan0 root tbf rate 1mbit burst 24b limit 10000 But I am in doubt many people are aware of that or occasionally, like me, have to find out the hard way they forgot to change it. So I was wondering if one of the following is acceptable / possible: - hint / assign the mentioned qdisc by default instead of none (no idea if that can be done from within a driver though) - take a transmission delay into account in the vcan driver itself. Looking forward to your opinions / ideas. With kind regards, Jeroen Hofstee
