Hello David,
On 12.08.22 14:37, Marc Kleine-Budde wrote:
On 11.08.2022 13:17:47, David Boles wrote:
Unfortunately it seems like this is happening at the layer of
individual sockets. Candump was already printing out messages that I
was "losing", and adding the -d flag doesn't affect its printout
(presumably since from its perspective, they haven't been dropped).
See the code that the "-d" command line options activates :)
| https://github.com/linux-can/can-utils/blob/master/candump.c#L650
... and add this to your app.
Run your program at a lower NICE value
You can try to receive several CAN frames with recvmmsg().
Good idea!
Make the queue as big as you can.
I the socket drops CAN frames, this means there's not enough CPU time
for your app to receive them all. You should look at your system and
find out where the CPU time is lost.
All these measures seem to be the last solution when nothing else helped.
Can you probably tell me more about your use-case?
1. e.g. when you are using the CAN_RAW socket: Do you set CAN filters to
pass only needed content into userspace?
When you drop 50% of the CAN IDs in userspace you still have to transfer
them from kernelspace to userspace and check if you should drop them.
2. when you need to filter for updates in specific content in the CAN
frames data[] section the CAN_BCM socket is your friend. Especially for
cyclic sent CAN messages e.g. in automotive use-cases.
3. When you need to forward and/or modify CAN frames between CAN
interfaces there is a special netlink-based in-kernel CAN-Gateway which
can be controlled by the 'cangw' tool.
The last time I had your described issues, I was routing CAN frames via
userspace - which finally led to the implementation of the can-gw module ;-)
Best regards,
Oliver
