PCAN and SocketCAN Questions

PCAN and SocketCAN Questions

[David Boles]

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?

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?

Question 3: I'd like to have as little latency as possible and I'm
assuming using PCIe cards would be beneficial over USB. 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? 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?

Thank you in advance!

David

Re: PCAN and SocketCAN Questions

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 3070 bytes --]

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 |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: PCAN and SocketCAN Questions

[David Boles]

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@pengutronix.de> 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 |

Re: PCAN and SocketCAN Questions

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 2875 bytes --]

On 11.08.2022 13:17:47, David Boles wrote:
> Thank you Marc and Tom for your suggestions! I have a few follow-ups:

I'm missing Tom's mail, seems it didn't make it to the mailing list.

> # 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).

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.

> 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.

We currently don't have an API for stopping/aborting CAN frames, the
only thing you can do is ifdown/ifup the interface.

> 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?

No - currently there's only the down/up method.

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 |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: PCAN and SocketCAN Questions

[Oliver Hartkopp]

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

Re: PCAN and SocketCAN Questions

[David Boles]

Hi Oliver,

> Can you probably tell me more about your use-case?

> 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 ;-)

Yep! Excellent guess :D For a few different reasons, that's basically
what I'm hoping to do. If it doesn't work out, I'll definitely dig
into your suggestions.

> All these measures seem to be the last solution when nothing else helped.

Fortunately I haven't actually had a problem with keeping up with
receiving frames, I was just hoping for something a little more robust
than "configure a large buffer and assume that your program is keeping
up because it has before". SO_RXQ_OVFL sounds like the correct answer
for me.

Thank you!

David

On Fri, Aug 12, 2022 at 6:01 AM Oliver Hartkopp <socketcan@hartkopp.net> wrote:
>
> 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
>
>

Re: PCAN and SocketCAN Questions

[David Boles]

Hi Marc,

> See the code that the "-d" command line options activates :)

Ah, duh, sorry! I think I need to work on my google-fu; I hadn't come
across the SO_RXQ_OVFL option. That looks like exactly what I was
hoping for.

> We currently don't have an API for stopping/aborting CAN frames, the
> only thing you can do is ifdown/ifup the interface.

Unfortunate, but it's great to get a firm answer on that. I'll work
around it for now.

Thank you!

David

On Fri, Aug 12, 2022 at 5:37 AM Marc Kleine-Budde <mkl@pengutronix.de> wrote:
>
> On 11.08.2022 13:17:47, David Boles wrote:
> > Thank you Marc and Tom for your suggestions! I have a few follow-ups:
>
> I'm missing Tom's mail, seems it didn't make it to the mailing list.
>
> > # 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).
>
> 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.
>
> > 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.
>
> We currently don't have an API for stopping/aborting CAN frames, the
> only thing you can do is ifdown/ifup the interface.
>
> > 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?
>
> No - currently there's only the down/up method.
>
> 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 |