CAN performance

[Deus1959]

Hello,
we are developing a device family based on an OSD3358 package.
New requirements have led to the fact that we have to re-evaluate the CAN performance.
We use the socket-CAN interface of a Linux OS (details about OS, drivers and analysis in the appendix or picture).
The CAN interface works with 1 MBit. In the test, 16 CAN frames with (11-bit identifier 8 data bytes, ID ascending from 0x101 to 0x110) are received every 5 ms.
The following has come to our attention:

1.
During reception, in some cases the sequence of the frames is not ascending (see example below).
We have a superimposed protocol which depends on the ascending order.
In cases where the order is not correct, we have to request repetitions, which leads to an additional load.
Unfortunately we have not found a way to influence the behavior of the RX-FIFO.
Checks with a CAN sniffer have shown that the frames are always in the expected order on the bus.

(picture within attachment “frame sequnece.png”)

Does anybody have a hint how we can improve the behaviour ?

2.
We noticed that the CPU load due to CAN communication is surprisingly high.
The CAN interrupt generates an average load of about 17% every 5 ms for the specified 16 frames.
The read function generates an additional load of approx. 18%. The execution time of the code after the read requires .

(picture within attachment “htop_thread.png”, “top.png”)

Does anyone see a possibility to reduce these loads ?

We are grateful for any help.
But we will be back in the office only from 07.01.2020.

Thank you for your efforts and to all a contemplative Christmas and a successful start into the new year.

 

• This topic was modified 4 years, 10 months ago by Deus1959.

Attachments:

1. 

   frame-sequnece.png
   

2. 

   htop_threads.png
   

3. 

   top.png
   

1. Systeminfo.txt
2. Systeminfo-1.txt

[Neeraj Dantu]

Hey Deus,

Thanks for the detailed description. An interesting related post on TI forums: https://e2e.ti.com/support/processors/f/791/t/333494#pi320966=1

The description presents a scenario where there can be out of order CAN frames as they are read by the processor.

There are other references in the driver that indicate that out of order reading of frames could happen: https://github.com/torvalds/linux/blob/master/drivers/net/can/c_can/c_can.c#L857

I would suggest trying a lower speed(500K) to see if the issue persists as high utilization has been linked to this behavior. Another way to solve the issue would be to use a DMA. It looks like from Table 11-24 in AM335x TRM that DCAN1 can utilize the EDMA(https://elinux.org/images/6/65/Spruh73c.pdf). But, there is currently no reference to DMA in the CAN driver code. So, it would likely require a device tree + driver modification

The performance is likely a result of frequency of interrupt generation and servicing. Can you check dmesg CAN driver messages to indicate any bad initialization such as described in https://e2e.ti.com/support/legacy_forums/embedded/linux/f/354/t/370865?AM335x-DCAN-High-load-of-CPU?

Neeraj

[Author]

Posts