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

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

[-- Attachment #1: Type: text/plain, Size: 2110 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.
> 
> I fail to see the remaining part of the problem.
> 

Consider a simple scenario consisting of a shared communication device
over which packets arrive and get time-stamped. Now, if applications
that receive those packets sit on different, unsynchronised CPUs, they
have to know on which CPU the time stamps were taken in order to relate
them to other events correctly. Basically the same issue you have on
distributed systems as well.

If we leave the user with broken local clocks, we _must_ provide the
information about the clock source. There are always scenarios where you
_cannot_ separate your applications in a way that they run totally
independent on different CPUs. And then we should provide means to
synchronise the clocks, or the user has to re-invent the wheel over and
over again. Given the latter, doing this inside the core in a
transparent manner is far smarter.

Jan


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