[prev in list] [next in list] [prev in thread] [next in thread] 

List:       orocos-users
Subject:    [Orocos-users] Comparing timestamps generated in rt and non-rt contexts
From:       adolfo.rodriguez () pal-robotics ! com (=?ISO-8859-1?Q?Adolfo_Rodr=EDguez_Tsouroukdis
Date:       2012-01-27 9:20:08
Message-ID: CAKuM+oJvbD4J=Q1vQ1T+7yG0iA+LKuQP4oadMDLpeL3=pisvcg () mail ! gmail ! com
[Download RAW message or body]

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

> 2012/1/19 Adolfo Rodr?guez Tsouroukdissian <
> adolfo.rodriguez at pal-robotics.com>:
> > 
> > 
> > On Wed, Jan 18, 2012 at 5:55 PM, Adolfo Rodr?guez Tsouroukdissian
> > <adolfo.rodriguez at pal-robotics.com> 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
> 



-- 
Adolfo Rodr?guez Tsouroukdissian
Robotics engineer
adolfo.rodriguez at pal-robotics.com
http://www.pal-robotics.com

PAL ROBOTICS S.L
c/ Pujades 77-79, 4?4?
08005 Barcelona, Spain.
Tel. +34.93.414.53.47
Fax.+34.93.209.11.09

AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos, pueden
contener informaci?n privilegiada y/o confidencial que est? dirigida
exclusivamente a su destinatario. Si usted recibe este mensaje y no es el
destinatario indicado, o el empleado encargado de su entrega a dicha
persona, por favor, notif?quelo inmediatamente y remita el mensaje original
a la direcci?n de correo electr?nico indicada. Cualquier copia, uso o
distribuci?n no autorizados de esta comunicaci?n queda estrictamente
prohibida.

CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may
contain confidential information which is privileged and intended only for
the individual or entity to whom they are addressed.  If you are not the
intended recipient, you are hereby notified that any disclosure, copying,
distribution or use of this e-mail and/or accompanying document(s) is
strictly prohibited.  If you have received this e-mail in error, please
immediately notify the sender at the above e-mail address.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mech.kuleuven.be/pipermail/orocos-users/attachments/20120127/ad5d72ff/attachment-0001.html \
                
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ClockOffsetService.h
Type: text/x-chdr
Size: 2010 bytes
Desc: not available
Url : http://lists.mech.kuleuven.be/pipermail/orocos-users/attachments/20120127/ad5d72ff/attachment-0001.bin \



[prev in list] [next in list] [prev in thread] [next in thread]