Thank you Marc and Tom for your suggestions! I have a few follow-ups: # Question 1: Silently losing received frames if the socket isn't read from frequently enough > See candump's "-d" command line option. 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). > Run your program at a lower NICE value Good idea! > Make the queue as big as you can. Yep, that's what I'm currently doing. It's probably an acceptable solution though not ideal; I'd like to be able to detect this happening and fail noisily. # Question 2: Behavior of one-shot and presume-ack It sounds like one-shot doesn't retry in the event of other problems (like losing arbitration) so that isn't what I want. It sounds like presume-ack is what I wanted but is only supported by very few devices, so I probably don't want to use it either. # New: Question 4 I think the right course of action is to detect (either via looped-back frames or maybe error frames, or something else) that my transceiver is the only one on the bus and to stop sending messages temporarily. I'd like to avoid sending excessively stale frames (e.g. if a new transceiver joins the bus five minutes later, it shouldn't receive a five minute old frame from me) and from my testing with PCAN-USB dongles they seem to try resending a frame endlessly. I'd also like to avoid missing receiving frames transmitted by any new transceivers on the bus. Is there any universal/reliable API for clearing all transmit buffers for an interface, down to the device itself, without affecting its ability to receive frames? Thanks again! David On Wed, Aug 10, 2022 at 12:45 AM Marc Kleine-Budde <mkl@xxxxxxxxxxxxxx> wrote: > > On 09.08.2022 19:35:09, David Boles wrote: > > Hello everyone, I'm new to both SocketCAN and mailing lists so please > > let me know if I'm making any faux pas or haven't correctly RTFMed! I > > heard this was the correct place to ask questions and I have a few > > that I haven't been able to find answers to. > > > > All my testing so far has been done on Ubuntu 20.04 with > > 5.15.0-43-generic and PCAN-USB( Pro) dongles and PCAN-PCI Express > > cards. > > > > Question 1: I've noticed that frames can get silently lost if my > > application doesn't read from the socket frequently enough. This also > > happens if I'm simultaneously dumping frames with candump (the "lost" > > frames do show up in candump's output). Increasing the socket receive > > buffer size with SO_RCVBUF allows more frames to be stored before new > > ones start getting lost. Is there a recommended way to detect this > > happening so that my program can fail noisily? > > See candump's "-d" command line option. > > | -d (monitor dropped CAN frames) > > > Question 2: I'd like to be able to send frames without other receivers > > on the bus to acknowledge them. The one-shot option seems to allow me > > to do this with my USB dongles. What's the difference between the > > one-shot and presume-ack options? > > In one shot mode the controller only sends the frame once, there's no > automatic retransmission in case of an error, i.e. missing ACK. This > means in the error case the error counters are incremented as usual and > if enabled and supported by the driver you receive a CAN error frame on > the socket. > > Refer to the m_can user manual > (https://github.com/hartkopp/M_CAN-User-Manual-History): > > | Disabled Automatic Retransmission > | > | According to the CAN Specification (see ISO 11898-1:2015, 8.3.4 Recovery > | Management), the M_CAN provides means for automatic retransmission of > | frames that have lost arbitration or that have been disturbed by errors > | during transmission. By default automatic retransmission is enabled. To > | support time-triggered communication as described in ISO 11898-1:2015, > | chapter 9.2, the automatic retransmission may be disabled via CCCR.DAR. > > Presume ACK, tells the hardware to presume the CAN frame was ACKed, this > results in no error and thus no retransmission. > > > Question 3: I'd like to have as little latency as possible and I'm > > assuming using PCIe cards would be beneficial over USB. > > ACK > > > Unfortunately > > my PCAN-PCI Express card doesn't seem to support either one-shot or > > presume-ack; is that a hardware limitation or a driver limitation? > > Maybe Stephane (Cc'ed) can answer this. > > > If > > it's a hardware limitation, would anyone be able to recommend a > > low-latency, full-featured option for CAN on traditional x86/64 > > desktops? > > regards, > Marc > > -- > Pengutronix e.K. | Marc Kleine-Budde | > Embedded Linux | https://www.pengutronix.de | > Vertretung West/Dortmund | Phone: +49-231-2826-924 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
