[lttng-dev] LTTng - Xenomai : different results between timestamp-lttng and rt_time_read()
MONTET Julien
julien.montet at reseau.eseo.fr
Thu May 20 03:58:20 EDT 2021
Hi the developers !
CONTEXT
I am currently working on a Raspberry pi 3B with Xenomai and LTTng tools.
Raspbian 10.9 Buster - kernel 4.19.85
uname -a : Linux raspberrypi 4.19.85-v7+ #5 SMP PREEMPT Wed May 12 10:13:37
Both tools are working, but I wonder about the accuracy of LTTng libraries.
METHOD
The code used is quite simple, it is written with the alchemy skin.
A rt_task_spawn calls a function that has rt_task_set_periodic(NULL, TM_NOW, period) and rt_task_wait_period(NULL).
->The rt_task_set_periodic is based on 1ms.
->The rt_task_wait_period(NULL) is of course inside a while loop (see below at the very end).
My goal is to get accurate traces from Xenomai.
I took two methods to do so :
-> lttng
-> basic calculation based on rt_timer_read()
What a surprise when I found both method have two different results.
-> LTTng shows me traces [0.870;1.13] ms (or even less precise)
-> rt_time_read shows me traces [0.980;1.020] ms
Thing to note :
-> The use of LTTng has no influence on rt_time_read(), you can use both methods at the same time.
Then, I saved the output of rt_time_read inside a tracepoint.
It appeared the LTTng is always called at the right time because the value got by rt_time_read () is really good.
QUESTIONS
These are now my questions :
- What is the method I should trust ?
- I have searched on the forum and I found LTTng uses a MONOTONIC clock for the timestamp. Can/Should I modify it ?
CODE
-----------------------------------------------------------------------
A small part of my function called by rt_task_spawn :
[...]
RTIME period = 1000*1000; // in ns
RTIME now;
RTIME previous = 0;
RTIME duration;
[...]
while(1)
{
overruns = 0;
err = rt_task_wait_period(&overruns);
now = rt_timer_read();
tracepoint(tp_provider, tracepoint_tick_ms, now, "tick");
if (previous != 0)
{
duration=now-previous;
rt_printf("%llu\n \n", duration/1000);
}
previous=now;
[...]
}
------------------------------------------------------------------------
Regards,
Julien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20210520/fa25ade1/attachment-0001.htm>
More information about the lttng-dev
mailing list