Re: [Xenomai-core] Getting the clock model right

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2801 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]