can, m_can, tcan4x5x : big jitter between the packets by sending

can, m_can, tcan4x5x : big jitter between the packets by sending

[Michael Anochin]

Hello,

my application continuously sends 64 bytes CANFD packets with 1MBit/s at 
the 10ms interval. I use tcan4450 on the RPI4 with 5.10.103 Kernel and 
raspbian. No other significant processes load the CPU.

When I monitor the traffic with a PCAN adapter on a Windows PC, I notice 
that the packets sometimes arrive with a delay of 5-9ms. But the next 
following packet arrive faster as 10ms. My desired interval of 10ms is 
kept at the jitter of +/- 9ms.

Running the App on only one CPU core using tasksel improve the jitter 
somewhat.

Am I the only one who observes such large jitter or is the m_can 
implementation at Perepherie (spi) not so fast from the throughput and 
is completely normal.

Maybe I should switch to 5.17 kernel? On 5.17 there are bulk read/write 
function for spi regmap.


Thanks and Best Regards,
Michael Anochin

Re: can, m_can, tcan4x5x : big jitter between the packets by sending

[Oliver Hartkopp]

Hi Michael,

On 19.05.22 17:52, Michael Anochin wrote:

> my application continuously sends 64 bytes CANFD packets with 1MBit/s at 
> the 10ms interval.

How does this application implement this 10ms interval?

Can you check whether

     cangen -g 10 -f -I 123 -L 64 can0

has the same problems?

With

     candump -td can0

you should be able to see some timestamp gaps around 10ms.

> I use tcan4450 on the RPI4 with 5.10.103 Kernel and 
> raspbian. No other significant processes load the CPU.
> 
> When I monitor the traffic with a PCAN adapter on a Windows PC, I notice 
> that the packets sometimes arrive with a delay of 5-9ms. But the next 
> following packet arrive faster as 10ms. My desired interval of 10ms is 
> kept at the jitter of +/- 9ms.
> 
> Running the App on only one CPU core using tasksel improve the jitter 
> somewhat.

What is the use-case for this 10ms cyclic transmission? Maybe the 
CAN_BCM (which uses in-kernel highres timers) could bring an improvement 
for you.

> Am I the only one who observes such large jitter or is the m_can 
> implementation at Perepherie (spi) not so fast from the throughput and 
> is completely normal.
> 
> Maybe I should switch to 5.17 kernel? On 5.17 there are bulk read/write 
> function for spi regmap.

I don't answer to this as I don't have the required SPI knowledge ... 
but if you could upgrade to a newer kernel this is always a good 
approach ;-)

Best regards,
Oliver

Re: can, m_can, tcan4x5x : big jitter between the packets by sending

[Oliver Hartkopp]

Hi Michael,

On 19.05.22 18:56, Michael Anochin wrote:

>> How does this application implement this 10ms interval?
> 
> I use epiktimer https://wiki.lazarus.freepascal.org/EpikTimer
> (https://github.com/graemeg/epiktimer) for freepascal compiler. It calls 
> fpsend (like "send" in c) very periodically to put the can_fd msg to the 
> buffer. No doubt on this. I think, the lag is in a m_can implementation. 

Ok.

> The interrupts are switched off briefly in m_can_isr 
> (m_can_disable_all_interrupts), may be one of IRQs goes lost or 
> something like this.

Hm. Do you plan to test the Linux 5.17 kernel to make use of the latest 
SPI improvements then?

>>> Can you check  cangen -g 10 -f -I 123 -L 64 can0
> Yes, I will do it tomorrow and report.

Good.

>>>      candump -td can0
> I see even greater jitter with candump -td. That's why I took the 
> separate CAN adapter for sniffing.

Ok.

>>> What is the use-case for this 10ms cyclic transmission? 
> The use-case is in the communication with car light (automotive sector).

Aah - I have a rough idea ;-)

>>> Maybe the CAN_BCM could bring an improvement 
> Unfortunately, the format of a broadcast message cannot be taken. There 
> is a package counter in each message, wich sould be incremented each time.

In fact the CAN_BCM is also capable to send a sequence(!) of CAN(FD) frames.

The nframes element in the struct bcm_msg_head can be e.g. 16 (4 bit 
counter) or even 256 (8 bit counter) so that you can create (or modify) 
a bigger array of CAN(FD) frames including the counter value or some 
checksums.

And then this array can be (asynchronously) pushed to the BCM socket for 
content updates while the cycle time for the proper and precise 
transmission is maintained in the kernel.

You should give it a try ;-)

Best regards,
Oliver


> 
> Am 19.05.2022 um 18:26 Oliver Hartkopp:
>> Hi Michael,
>>
>> On 19.05.22 17:52, Michael Anochin wrote:
>>
>>> my application continuously sends 64 bytes CANFD packets with 1MBit/s 
>>> at the 10ms interval.
>>
>> How does this application implement this 10ms interval?
>>
>> Can you check whether
>>
>>      cangen -g 10 -f -I 123 -L 64 can0
>>
>> has the same problems?
>>
>> With
>>
>>      candump -td can0
>>
>> you should be able to see some timestamp gaps around 10ms.
>>
>>> I use tcan4450 on the RPI4 with 5.10.103 Kernel and raspbian. No 
>>> other significant processes load the CPU.
>>>
>>> When I monitor the traffic with a PCAN adapter on a Windows PC, I 
>>> notice that the packets sometimes arrive with a delay of 5-9ms. But 
>>> the next following packet arrive faster as 10ms. My desired interval 
>>> of 10ms is kept at the jitter of +/- 9ms.
>>>
>>> Running the App on only one CPU core using tasksel improve the jitter 
>>> somewhat.
>>
>> What is the use-case for this 10ms cyclic transmission? Maybe the 
>> CAN_BCM (which uses in-kernel highres timers) could bring an 
>> improvement for you.
>>
>>> Am I the only one who observes such large jitter or is the m_can 
>>> implementation at Perepherie (spi) not so fast from the throughput 
>>> and is completely normal.
>>>
>>> Maybe I should switch to 5.17 kernel? On 5.17 there are bulk 
>>> read/write function for spi regmap.
>>
>> I don't answer to this as I don't have the required SPI knowledge ... 
>> but if you could upgrade to a newer kernel this is always a good 
>> approach ;-)
>>
>> Best regards,
>> Oliver

Re: can, m_can, tcan4x5x : big jitter between the packets by sending

[Marc Kleine-Budde]

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

On 19.05.2022 17:52:36, Michael Anochin wrote:
> my application continuously sends 64 bytes CANFD packets with 1MBit/s at the
> 10ms interval. I use tcan4450 on the RPI4 with 5.10.103 Kernel and raspbian.
> No other significant processes load the CPU.
> 
> When I monitor the traffic with a PCAN adapter on a Windows PC, I notice
> that the packets sometimes arrive with a delay of 5-9ms. But the next
> following packet arrive faster as 10ms. My desired interval of 10ms is kept
> at the jitter of +/- 9ms.
> 
> Running the App on only one CPU core using tasksel improve the jitter
> somewhat.
> 
> Am I the only one who observes such large jitter or is the m_can
> implementation at Perepherie (spi) not so fast from the throughput and is
> completely normal.
> 
> Maybe I should switch to 5.17 kernel? On 5.17 there are bulk read/write
> function for spi regmap.

The tcan4x5x driver is not really optimized. Don't expect great
performance with it. At least the newer kernel have some kind of
optimization. There are a lot of further optimization opportunities
which are already implemented in the mcp251xfd driver.

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