Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> 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). > > What about emitting Adeos events when receiving NTP corrections ? This > way, we would avoid reinventing NTP ? >
IIRC, NTP was designed to synchronise clocks over unreliable and slow media. The math behind it /may/ be useful (though it may also turn out to be too heavy), but beyond that... Already seen a NTP-over-CAN realisation, e.g.? And what would NTP over standard network buy us on a Xenomai system when the accuracy of NTP time stamps taken under Linux gets additionally degraded by Xenomai activity? I thought about NTP for our problem for a short while, but then quickly dropped the idea due to lacking guarantees. Likely, we rather need something like IEEE 1588, but there are unfortunate patents around that protocol.
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core