Erik Rull
2018-11-05 18:59:10 UTC
Hi all,
I have some rt_printk-outputs in hard realtime context.
They have the kernel timestamp in front of each log line.
I have not yet figured out why, but sometimes this timestamp seems to stop
incrementing for some successive rt_printks but keeping the pace of the clock
later (so no clock tick loss) - even if there is "a lot of" time between the
rt_printks - kernel got scheduled in between. It seems as if gaps of < 150usec
sometimes increment the printk-timestamp, sometimes not.
What could be the reason for this? The system has enough idle time to schedule
the kernel and it seems as if it is not predictable when this effect happens and
when not.
rt_get_real_time_ns() seems to deliver a correct time even in hard realtime / in
interrupt context.
RTAI is 4.0 and kernel is 3.4.67.
Thanks!
Best regards,
Erik
I have some rt_printk-outputs in hard realtime context.
They have the kernel timestamp in front of each log line.
I have not yet figured out why, but sometimes this timestamp seems to stop
incrementing for some successive rt_printks but keeping the pace of the clock
later (so no clock tick loss) - even if there is "a lot of" time between the
rt_printks - kernel got scheduled in between. It seems as if gaps of < 150usec
sometimes increment the printk-timestamp, sometimes not.
What could be the reason for this? The system has enough idle time to schedule
the kernel and it seems as if it is not predictable when this effect happens and
when not.
rt_get_real_time_ns() seems to deliver a correct time even in hard realtime / in
interrupt context.
RTAI is 4.0 and kernel is 3.4.67.
Thanks!
Best regards,
Erik