Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Hi,
>> recent announcement of some new TSC synchronisation feature in RTAI made
>> me stick my nose into this and think about the whole issue of clock
>> synchronisation again. Well, let's not talk about RTAI details here, but
>> they got one thing right: as long as we cannot handle unsynch'ed TSC on
>> SMP, we need some detection and alarming as the bare minimum.
>> Why can't we handle such cases yet? First, there seems to be still some
>> bugs hidden in the core (one example: xntimer_start_aperiodic() uses the
>> local time stamp to start a remote timer).
> Reading the code, there seem to be only two places where the local tsc
> is used to set a remote timer, it is xntimer_start_aperiodic, and
> xntimer_move_aperiodic, which is used by xntimer_migrate. So we are left
> with only one bug: starting a timer on the remote CPU, this could easily
> be implemented with a queue which would be handled by the timer IPI.

As I said: fixable based on thorough review - but only a minor part of
the problem.

>> (...)
>> for smoothly adjusting clocks during runtime would be great. I'm
>> thinking about a generic infrastructure to synchronise the Xenomai time
>> on external sources (=>distributed clocks).
> What do you want, NTP ? Or calling xnpod_settime periodically ?

More like NTP: monotonic clocks that can be derived from custom
synchronisation signals, maybe optimised/simplified with fact in mind
that those signals should have bounded worst-case jitters (on a hard
real-time system like Xenomai).

We just implemented such synchronisation based on CAN and serial
null-modem signals. RTnet comes with a high-quality distributed clock as
well. We have not yet implemented a smart clock adjustment (specifically
because our application only needs about 1 millisecond accuracy).


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to