[Xenomai] latency test and mercury
nolange79 at gmail.com
Wed Feb 22 13:40:09 CET 2017
That clears up the wrong idea I had about Mercury, I though of it as a
framework to hook into the most essential IRQs.
As said the kernel in question is the standard debian 4.9 with a ton
of drivers, so I guess its quite hopeless narrowing down the issue
with this as baseline.
It was attempt to get a quick peek at Xenomai without building a system for it.
2017-02-22 9:59 GMT+01:00 Philippe Gerum <rpm at xenomai.org>:
> On 02/21/2017 07:37 PM, Norbert Lange wrote:
>> I got some really big variations on the latency test (up to 4ms), but
>> I am not exactly sure if this supposed the realtime portion.
> This means that the underlying native kernel Mercury depends on has a
> latency issue for sure.
>> I am unable to run kernel or irq tests.
> That is expected, since a kernel module implementing those tests is
> required, but only Cobalt provides it so far. Such module is based on
> Xenomai's RTDM kernel interface, which we don't have for Mercury (to be
> precise, we have a 10-years old POC for it which would need significant
>> For a user thread, this is probably like expected since this is a full
>> debian desktop with RT kernel.
>> If I understood the mercury model right, I could create kernel modules
>> with realtime behaviour, Is there any test for latency amongst those?
>> (Documentation is rather light on mercury)
> Mercury is basically providing a way to run the non-POSIX Xenomai APIs
> over a native kernel, nothing more than this. Said differently, this is
> a purely user-space thing, which does not introduce any kernel support.
> The idea behind Mercury is to allow running the RTOS emulators Xenomai
> provides (e.g. vxworks and psos) without dragging in the co-kernel
> support Cobalt introduces, which may not be required by some legacy
> applications ported to Linux, for which real-time performances are not
> actually critical. If one wants to go for the POSIX interface
> exclusively, then Mercury brings no value at all.
> So Mercury fully depends on the real-time capabilities of the "regular"
> Linux kernel underneath for that matter, whether it includes the
> PREEMPT_RT patch or not.
>> I can rule out SMI interaction, the count of those is not increasing.
> The latency test code (testsuite/latency/latency.c) is shared between
> Mercury and Cobalt cores, the major difference is that POSIX services
> this code invokes are obtained from the glibc or libcolbalt - which
> contains the syscall interface to the Cobalt co-kernel, respectively.
> You may want to check for issues which are specific to running real-time
> code over native kernels, like SCHED_FIFO throttling (although I doubt
> it would trigger with the latency test).
More information about the Xenomai