On 2025-01-28 16:29:27 [+0100], Pavel Pisa wrote: > Please check if you find some problematic choices. I didn't find anything obviously wrong. Assuming your CPU is busy in general you could remove NO_HZ in favour of PERIODIC. This is however not to cause spikes you describe below. > The cyclic test worked well, and we have even delivered two systems > to OSADL QA real-time farm > > https://www.osadl.org/?id=4109 It shows "IRQ work interrupts". Not sure what causes them. > However, the CAN/CAN FD communication latency measured on the CTU CAN FD IP > core is far from optimal. Some runs under load with > 10 msec latency. Our own CAN FD stack for RTEMS keeps with no exception > under 60 usec on the same hardware. > > I understand that the Linux socket layer and networking > stack are complex, and many optimizations are ahead. > We will be happy to contribute where we can and find time > and even some resources to engage more students etc... > > But I would like to be sure that the bad results are not > caused by our mistakes in configuration. You have CAN and "regular networking". My guess would be that regular networking blocks blocks BH and so your CAN. You could try to have all interrupts serviced on CPU0 and move CAN to CPU1. If so this should improve then. Other than that, I would suggest to get some tracing to see what delays your CAN interrupts and/ or handling in general. > I will be happy to meet you and discuss Linux and other > control and real-time areas at FOSDEM 2025. I should be able to make it. … > Slides in English which I want to update/correct for FOSDEM > > https://talks.openalt.cz/media/openalt-2024/submissions/3XTMDF/resources/openalt24_linux_for_rt-reduced_FbZPuS0.pdf looks good. If you want additional history points, I have some at https://files.speakerdeck.com/presentations/0620b5b3a00b42fc91fba6cc4092d278/KR_2024_PREEMPT_RT_over_the_years.pdf Slide 11 - 21. However you have most of the pieces so. > Best wishes, > > Pavel > Sebastian
