All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@domain.hid>
To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Cc: xenomai-core <xenomai@xenomai.org>
Subject: Re: [Xenomai-core] Getting the clock model right
Date: Fri, 06 Apr 2007 16:29:23 +0200	[thread overview]
Message-ID: <46165943.3050706@domain.hid> (raw)
In-Reply-To: <46164F5D.4080301@domain.hid>

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

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).

Jan


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

  reply	other threads:[~2007-04-06 14:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-06 12:07 [Xenomai-core] Getting the clock model right Jan Kiszka
2007-04-06 13:47 ` Gilles Chanteperdrix
2007-04-06 14:29   ` Jan Kiszka [this message]
2007-04-06 15:13     ` Gilles Chanteperdrix
2007-04-06 16:36       ` Jan Kiszka
     [not found]     ` <461677BB.1090301@domain.hid>
2007-04-06 16:54       ` Jan Kiszka
2007-04-06 17:06         ` Jan Kiszka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46165943.3050706@domain.hid \
    --to=jan.kiszka@domain.hid \
    --cc=gilles.chanteperdrix@xenomai.org \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.