Re: AW: Call today

[Philippe Gerum <rpm@xenomai.org>]

"Richard Weinberger" <richard@nod.at> writes:

> Am Wed, Oct 14, 2026, 11:51 schrieb Jan Kiszka <jan.kiszka@siemens.com>:
>> > I was about to ask whether somebody has (long term) latency plots
>> > for i.MX8M mini SoCs.
>> > 
>> 
>> We do not have one in CI lab, but Philippe has/had one in scope for
>> Xenomai 4 and may have related numbers from his lab.
>
> Would be good to have some solid numbers.
> On my i.mx8mm board I see latencies around 45us.
> What worries me a bit, copying memory on a different CPU in
> a Linux task significantly increases the latency up to 100us.
>

My experience with the Variscite Dart i.MX8M Mini back in 2020 has not
been that nice either. Structural latencies observed were > 200 us with
a 10Khz loop, on any attempt with every rt option: x3, x4, preempt-rt,
all the same. I was using the Variscite kernel fork of the NXP kernel
fork... Way too many forks on this table, so I cannot tell whether some
gremlin was hiding in the bsp layer which would have explained
this. That was roughly enough to sustain real-time audio requirements at
that time, but certainly not good enough for stricter requirements. This
said, those measurements date back to 2020 (kernel 4.19.35), so things
might have evolved since then, take my word with a grain of salt when it
comes to the current status of this series.

Last year, I ran evl on a Phytec i.MX8M "Pollux" board. Much better
figures (read: something we can use), but running evl for a short time
only on this board was purely opportunistic, because this target was not
aimed at real-time work and left my desk early.

PS: The issue you mentioned about seeing weird figures when memory
traffic happens between different CPUs rings a bell. Back in 2022, I did
some measurements on a TI am625 SoC, observing high impact on an
isolated CPU running the latency test, caused by tasks running on other
CPUs, moving memory around and switching context at high rate, to the
point where using this platform for real-time duty was a non-starter. A
peculiarity which must have had a reasonable explanation is that the
busier the CPU core running the sampling loop, the (really, really)
better the results. I sent some questions to TI about the whole issue at
that time, a TI engineer answered that the problem was under
investigation, then the discussion stalled, and I did not get back to
it. Again, this is old news, so the situation may have improved
(hopefully).

-- 
Philippe.