On Thu, Jan 26, 2012 at 11:56 PM, Peter Soetens <peter [..] ...>wrote:

> 2012/1/19 Adolfo Rodríguez Tsouroukdissian <
> adolfo [dot] rodriguez [..] ...>:
> >
> >
> > On Wed, Jan 18, 2012 at 5:55 PM, Adolfo Rodríguez Tsouroukdissian
> > <adolfo [dot] rodriguez [..] ...> wrote:
> >>
> >> All,
> >>
> >> This is a slightly OT question, but I'd like to hear your opinion on the
> >> subject, if you have one.
> >>
> >> I have a realtime compoent that needs to compare timestamps coming from
> >> the outside via clock_gettime(CLOCK_REALTIME, &tv) with timestamps
> generated
> >> by itself, currently via Xenomai's rt_timer_read(). The two timestamps
> do
> >> not share a common origin, and their offset is subject to drift (eg. as
> a
> >> consequence of NTP syncing).
> >>
> >> The only clean solution I've found so far is to upgrade to the very
> recent
> >> (Nov-2011) Xenomai 2.6, and use clock_gettime(CLOCK_HOST_REALTIME, &tv)
> of
> >> the posix skin, which is a real-time clock synchronized with the Linux
> clock
> >> [1, 2].
> >>
> >> This is the first time I face this issue, but I'm pretty sure that I'm
> not
> >> the first one to face it, so I'm interested in knowing how some of you
> might
> >> have dealt with it: manually messing around with offsets?, how about
> drift
> >> over time?.
> >
> >
> > More datail on how I'd code a solution without Xenomai 2.6: Create a
> > component linked against the realtime libraries, xenomai in my case, but
> > scheduled by ORO_SHED_OTHER, and periodically compute the current offset
> > between clocks, hence taking into account clock drift issues. Hackish and
> > unelegant, but the best I can think of.
>
> There are discussions about this on the Xenomai mailing list. Most
> people have a non-Xenomai thread (plain posix) reading gettimeofday
> and storing this somewhere, protected by a posix (non-Xenomai) mutex.
> A xenomai thread then regularly reads this time (grabbing the mutex
> and switching to secondary mode) and calculates the offset wrt the
> Xenomai clock.

I ended up doing something similar to this, but instead of storing time, I
store the offset between the rt and system clock references. If you store
system time, and need to query it at high rates, you need to spin a
non-realtime thread pretty fast, and your timestamps may be offset by as
much as a thread frequency period (or more if your scheduler can't keep
up). Not nice.
Conversely, if you store the offset between clocks, you can spin your
non-realtime thread at a more lazy frequency (inter-clock-drift should have
pretty slow dynamics), and generate timestamps from your realtime thread
with as much granularity as you wish.

I have attached a stripped-down 1.x example component that does this. I
have left out the interface to other components, as it can be implemented
in different ways, depending on what you want (offset, timestamp conversion
or timestamp generation) or how you want it (data flow, operations).

> As I understood it, A Xenomai task should never-never read
> gettimeofday, since this can deadlock. See also:
> http://bugs.orocos.org/show_bug.cgi?id=881
>

Correct, gettimeofday should not be used, but equally important,
clock_gettime(CLOCK_HOST_REALTIME, &tv) shouldn't be used either. I believe
that in some implementations they even share the same backend.

Thanks for your thoughts.

Adolfo.

> Peter
>