Hello Marc,
On 4/17/2023 2:26 PM, Marc Kleine-Budde wrote:
On 17.04.2023 19:34:03, Oliver Hartkopp wrote:
On 17.04.23 09:26, Marc Kleine-Budde wrote:
On 16.04.2023 21:46:40, Oliver Hartkopp wrote:
I had the 5ms that are actually used in the code in mind. But this is a
good calculation.
@Judith: Can you acknowledge the value calculation?
The "shortest" 11 bit CAN ID CAN frame is a Classical CAN frame with DLC = 0
and 1 Mbit/s (arbitration) bitrate. This should be 48 bits @1Mbit => ~50
usecs
So it should be something about
50 usecs * (FIFO queue len - 2)
Where does the "2" come from?
I thought about handling the FIFO earlier than it gets completely "full".
The fetching routine would need some time too and the hrtimer could also
jitter to some extend.
I was assuming something like this.
I would argue that the polling time should be:
50 µs * FIFO length - IRQ overhead.
The max IRQ overhead depends on your SoC and kernel configuration.
I just tried an educated guess to prevent the FIFO to be filled up
completely. How can you estimate the "IRQ overhead"? And how do you catch
the CAN frames that are received while the IRQ is handled?
We're talking about polling, better call it "overhead" or "latency from
timer expiration until FIFO has at least one frame room". This value
depends on your system.
It depends on many, many factors, SoC, Kernel configuration (preempt RT,
powersaving, frequency scaling, system load. In your example it's 100
µs. I wanted to say there's an overhead (or latency) and we need enough
space in the FIFO, to cover it.
I am not sure how to estimate IRQ overhead, but FIFO length should be 64
elements.
50 us * 62 is about 3.1 ms and we are using 1 ms timer polling interval.
Running a few benchmarks showed that using 0.5 ms timer polling interval
starts to take a toll on CPU load, that is why I chose 1 ms polling
interval.
regards,
Judith
