[Xenomai-help] Xenomai and timers.

[Xenomai-help] Xenomai and timers.

[Chris Stone]

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


I am trying to determine if Xenomai will help me to solve a problem I am having with embedded Linux in a real time environment. To set the context of the problem I am trying to solve, some background is necessary.

Our application area is telecommunications, we build cards for optical transport applications. We have recently transitioned from using Green Hills Velocity to embedded Linux as our real time operating system. Our applications are complex and multi-tasking and they use standard solutions such as semaphores to serialize access to shared data. In our first port of the Green Hills Velocity code to embedded Linux we often used sem_timedwait() to wait for a semaphore for a bounded amount of time. However, Linux appears to have an issue with timers when a task changes the clock with clock_settime().

The POSIX specification for clock_settime() states that: “Setting the value of the CLOCK_REALTIME clock via clock_settime() shall have no effect on threads that are blocked waiting for a relative time service based upon this clock, including the nanosleep() function; nor on the expiration of relative timers based upon this clock. Consequently, these time services shall expire when the requested relative interval elapses, independently of the new or old value of the clock.”

Additionally, the Linux man page for clock_settime() states that: “All implementations support the system-wide realtime clock, which is identified by CLOCK_REALTIME. Its time represents seconds and nanoseconds since the Epoch. When its time is changed, timers for a relative interval are unaffected, but timers for an absolute point in time are affected”. This indicates that the Linux implementation of clock_settime() follows the POSIX specification, as expected. Also the Linux implementation of nanosleep() uses relative timers, as expected.

However, almost all Linux API functions use absolute timer intervals. For instance, the man page for sem_timedwait() states that the timeout is an absolute interval meaning that it will be affected by clock changes. Thus, if task A is blocked in a sem_timedwait() call, and task B moves time forward with clock_settime(), then task A will return from sem_timedwait() with ETIMEOUT prematurely.

>From my examination of the documentation on Xenomai, it would appear that Xenomai does not suffer from this problem, but I would like to confirm my impression. My question to this list is, in Xenomai, if one calls rt_sem_p() with a timeout, will that timeout be correct even if a task changes the clock with clock_settime()?

Additionally, the documentation of the POSIX skin of Xenomai indicates that sem_timedwait() uses an absolute timeout. So, is the Xenomai version of sem_timedwait() vulnerable to clock changes? Do I have to use rt_sem_p() in order to avoid issues with clock changes?

Thanks in advance.
Christopher Stone
Optelian, Inc.



 		 	   		  

[-- Attachment #2: Type: text/html, Size: 3157 bytes --]

Re: [Xenomai-help] Xenomai and timers.

[Philippe Gerum]

On Thu, 2010-12-16 at 13:55 -0400, Chris Stone wrote:
> I am trying to determine if Xenomai will help me to solve a problem I
> am having with embedded Linux in a real time environment. To set the
> context of the problem I am trying to solve, some background is
> necessary.
> 
> Our application area is telecommunications, we build cards for optical
> transport applications. We have recently transitioned from using Green
> Hills Velocity to embedded Linux as our real time operating system.
> Our applications are complex and multi-tasking and they use standard
> solutions such as semaphores to serialize access to shared data. In
> our first port of the Green Hills Velocity code to embedded Linux we
> often used sem_timedwait() to wait for a semaphore for a bounded
> amount of time. However, Linux appears to have an issue with timers
> when a task changes the clock with clock_settime().
> 
> The POSIX specification for clock_settime() states that: “Setting the
> value of the CLOCK_REALTIME clock via clock_settime() shall have no
> effect on threads that are blocked waiting for a relative time service
> based upon this clock, including the nanosleep() function; nor on the
> expiration of relative timers based upon this clock. Consequently,
> these time services shall expire when the requested relative interval
> elapses, independently of the new or old value of the clock.”
> 
> Additionally, the Linux man page for clock_settime() states that: “All
> implementations support the system-wide realtime clock, which is
> identified by CLOCK_REALTIME. Its time represents seconds and
> nanoseconds since the Epoch. When its time is changed, timers for a
> relative interval are unaffected, but timers for an absolute point in
> time are affected”. This indicates that the Linux implementation of
> clock_settime() follows the POSIX specification, as expected. Also the
> Linux implementation of nanosleep() uses relative timers, as expected.
> 
> However, almost all Linux API functions use absolute timer intervals.
> For instance, the man page for sem_timedwait() states that the timeout
> is an absolute interval meaning that it will be affected by clock
> changes. Thus, if task A is blocked in a sem_timedwait() call, and
> task B moves time forward with clock_settime(), then task A will
> return from sem_timedwait() with ETIMEOUT prematurely.
> 
> From my examination of the documentation on Xenomai, it would appear
> that Xenomai does not suffer from this problem, but I would like to
> confirm my impression. My question to this list is, in Xenomai, if one
> calls rt_sem_p() with a timeout, will that timeout be correct even if
> a task changes the clock with clock_settime()?
> 
> Additionally, the documentation of the POSIX skin of Xenomai indicates
> that sem_timedwait() uses an absolute timeout. So, is the Xenomai
> version of sem_timedwait() vulnerable to clock changes? Do I have to
> use rt_sem_p() in order to avoid issues with clock changes?


Well, the POSIX behavior just makes sense, the kernel does not have to
figure out that in fact, your code is not immune to system time updates
so as to eventually consider absolute timeout specs as being relative
ones in disguise.

Therefore I would not speak about vulnerability here, it is just how
POSIX works, because absolute timeouts do have an advantage over
relative timeouts. Since Xenomai's POSIX skin wants to comply with the
standard, it does resume outstanding timers which end up having a
trigger date in the past due to a clock_settime() request.

The native Xenomai skin - which rt_sem_p is part of - has both relative
and absolute timeout forms. The relative form won't be sensitive to
system time updates, whilst the absolute form will. So you may want to
switch skins, or fix your POSIX code to explicitly deal with this issue.
YMMV. (I would probably fix my code actually).

> 
> Thanks in advance.
> Christopher Stone
> Optelian, Inc.
> 
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

-- 
Philippe.

Re: [Xenomai-help] Xenomai and timers.

[Chris Stone]

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


Thanks for your reply, and I realize that I am now getting off topic for this list, but if the explanation is easy perhaps I could impose on you a little further. How does one fix the POSIX code to deal with this issue? When sem_timedwait() returns with ETIMEDOUT, how does one know that the time was changed by another task and the timeout was not the duration that was asked for? 

Chris.

> Subject: Re: [Xenomai-help] Xenomai and timers.
> From: rpm@xenomai.org
> To: chris.linux@domain.hid
> CC: xenomai@xenomai.org
> Date: Thu, 16 Dec 2010 19:40:10 +0100
> 
> On Thu, 2010-12-16 at 13:55 -0400, Chris Stone wrote:
> > I am trying to determine if Xenomai will help me to solve a problem I
> > am having with embedded Linux in a real time environment. To set the
> > context of the problem I am trying to solve, some background is
> > necessary.
> > 
> > Our application area is telecommunications, we build cards for optical
> > transport applications. We have recently transitioned from using Green
> > Hills Velocity to embedded Linux as our real time operating system.
> > Our applications are complex and multi-tasking and they use standard
> > solutions such as semaphores to serialize access to shared data. In
> > our first port of the Green Hills Velocity code to embedded Linux we
> > often used sem_timedwait() to wait for a semaphore for a bounded
> > amount of time. However, Linux appears to have an issue with timers
> > when a task changes the clock with clock_settime().
> > 
> > The POSIX specification for clock_settime() states that: “Setting the
> > value of the CLOCK_REALTIME clock via clock_settime() shall have no
> > effect on threads that are blocked waiting for a relative time service
> > based upon this clock, including the nanosleep() function; nor on the
> > expiration of relative timers based upon this clock. Consequently,
> > these time services shall expire when the requested relative interval
> > elapses, independently of the new or old value of the clock.”
> > 
> > Additionally, the Linux man page for clock_settime() states that: “All
> > implementations support the system-wide realtime clock, which is
> > identified by CLOCK_REALTIME. Its time represents seconds and
> > nanoseconds since the Epoch. When its time is changed, timers for a
> > relative interval are unaffected, but timers for an absolute point in
> > time are affected”. This indicates that the Linux implementation of
> > clock_settime() follows the POSIX specification, as expected. Also the
> > Linux implementation of nanosleep() uses relative timers, as expected.
> > 
> > However, almost all Linux API functions use absolute timer intervals.
> > For instance, the man page for sem_timedwait() states that the timeout
> > is an absolute interval meaning that it will be affected by clock
> > changes. Thus, if task A is blocked in a sem_timedwait() call, and
> > task B moves time forward with clock_settime(), then task A will
> > return from sem_timedwait() with ETIMEOUT prematurely.
> > 
> > From my examination of the documentation on Xenomai, it would appear
> > that Xenomai does not suffer from this problem, but I would like to
> > confirm my impression. My question to this list is, in Xenomai, if one
> > calls rt_sem_p() with a timeout, will that timeout be correct even if
> > a task changes the clock with clock_settime()?
> > 
> > Additionally, the documentation of the POSIX skin of Xenomai indicates
> > that sem_timedwait() uses an absolute timeout. So, is the Xenomai
> > version of sem_timedwait() vulnerable to clock changes? Do I have to
> > use rt_sem_p() in order to avoid issues with clock changes?
> 
> 
> Well, the POSIX behavior just makes sense, the kernel does not have to
> figure out that in fact, your code is not immune to system time updates
> so as to eventually consider absolute timeout specs as being relative
> ones in disguise.
> 
> Therefore I would not speak about vulnerability here, it is just how
> POSIX works, because absolute timeouts do have an advantage over
> relative timeouts. Since Xenomai's POSIX skin wants to comply with the
> standard, it does resume outstanding timers which end up having a
> trigger date in the past due to a clock_settime() request.
> 
> The native Xenomai skin - which rt_sem_p is part of - has both relative
> and absolute timeout forms. The relative form won't be sensitive to
> system time updates, whilst the absolute form will. So you may want to
> switch skins, or fix your POSIX code to explicitly deal with this issue.
> YMMV. (I would probably fix my code actually).
> 
> > 
> > Thanks in advance.
> > Christopher Stone
> > Optelian, Inc.
> > 
> > 
> > 
> > _______________________________________________
> > Xenomai-help mailing list
> > Xenomai-help@domain.hid
> > https://mail.gna.org/listinfo/xenomai-help
> 
> -- 
> Philippe.
> 
> 
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 5809 bytes --]

Re: [Xenomai-help] Xenomai and timers.

[Gilles Chanteperdrix]

Chris Stone wrote:
> Thanks for your reply, and I realize that I am now getting off topic
> for this list, but if the explanation is easy perhaps I could impose
> on you a little further. How does one fix the POSIX code to deal with
> this issue? When sem_timedwait() returns with ETIMEDOUT, how does one
> know that the time was changed by another task and the timeout was
> not the duration that was asked for?

The answer is that POSIX is a big mess with regard to this issue... Some
functions allow to choose between relative and absolute timeouts
(clock_nanosleep, timer_settime), others allow to change the clock
(pthread_cond_timedwait), since using CLOCK_MONOTONIC automatically
solves this issue, some use relative timeouts. Others such as
sem_timedwait, pthread_mutex_timedlock pthread_timedjoin, offer no choice.

We could add some pthread_mutexattr_setclock_np and sem_setclock_np
services, but then your code would only run with Xenomai, which makes
POSIX a little less useful.

Note that usually, a timeout is an unexpected rare event not in need for
a lot of precision, and clock_settime should not make big jumps, I do
not think using sem_timedwait to create a periodic task was the plan.
Also note that Xenomai and Linux clock are separated, so, if Linux calls
clock_settime, Xenomai timers will not see it.

-- 
                                                                Gilles.

Re: [Xenomai-help] Xenomai and timers.

[Philippe Gerum]

On Thu, 2010-12-16 at 15:30 -0400, Chris Stone wrote:
> Thanks for your reply, and I realize that I am now getting off topic
> for this list, but if the explanation is easy perhaps I could impose
> on you a little further. How does one fix the POSIX code to deal with
> this issue? When sem_timedwait() returns with ETIMEDOUT, how does one
> know that the time was changed by another task and the timeout was not
> the duration that was asked for? 

I'm excluding small time adjustments, NTP-like, which should not be an
issue, because timeouts are not for accurate timing, but really for
implementing a safety belt against infinite hangs, so this is coarse
grained in essence. I'm talking about large arbitrary leaps forward done
using clock_settime() from an application context.

A possible answer then, is two fold:

- you likely control all the code running on your embedded platform,
which should include the task(s) issuing clock_settime(). Flagging this
particular action so that other tasks could detect it later on should be
possible. It should even be possible to exclude system time updates
using a rwlock mechanism when other tasks are about to pend on a timed
sync. Waiters would pick the read side before pending on the sync, the
task issuing clock_settime() would have to grab the write side before
changing time. In effect, this might postpone the system time update
until all waiters have either received the resource or hit a timeout
condition, but maybe this is acceptable for you.

- upon ETIMEDOUT condition, if the difference between clock_gettime()
when returning, and clock_gettime() before sleeping is preposterously
larger than the specified timeout, then the code may assume a system
time update took place, and act upon accordingly.  The cost here is one
syscall more issued unconditionally before entering the timed wait to
get the current time, but this may be acceptable as well. The grey area
is for updates in the range of the typical timeout value, you would
likely have to rely on something like the previous option instead.

> 
> Chris.
> 
> > Subject: Re: [Xenomai-help] Xenomai and timers.
> > From: rpm@xenomai.org
> > To: chris.linux@domain.hid
> > CC: xenomai@xenomai.org
> > Date: Thu, 16 Dec 2010 19:40:10 +0100
> > 
> > On Thu, 2010-12-16 at 13:55 -0400, Chris Stone wrote:
> > > I am trying to determine if Xenomai will help me to solve a
> problem I
> > > am having with embedded Linux in a real time environment. To set
> the
> > > context of the problem I am trying to solve, some background is
> > > necessary.
> > > 
> > > Our application area is telecommunications, we build cards for
> optical
> > > transport applications. We have recently transitioned from using
> Green
> > > Hills Velocity to embedded Linux as our real time operating
> system.
> > > Our applications are complex and multi-tasking and they use
> standard
> > > solutions such as semaphores to serialize access to shared data.
> In
> > > our first port of the Green Hills Velocity code to embedded Linux
> we
> > > often used sem_timedwait() to wait for a semaphore for a bounded
> > > amount of time. However, Linux appears to have an issue with
> timers
> > > when a task changes the clock with clock_settime().
> > > 
> > > The POSIX specification for clock_settime() states that: “Setting
> the
> > > value of the CLOCK_REALTIME clock via clock_settime() shall have
> no
> > > effect on threads that are blocked waiting for a relative time
> service
> > > based upon this clock, including the nanosleep() function; nor on
> the
> > > expiration of relative timers based upon this clock. Consequently,
> > > these time services shall expire when the requested relative
> interval
> > > elapses, independently of the new or old value of the clock.”
> > > 
> > > Additionally, the Linux man page for clock_settime() states that:
> “All
> > > implementations support the system-wide realtime clock, which is
> > > identified by CLOCK_REALTIME. Its time represents seconds and
> > > nanoseconds since the Epoch. When its time is changed, timers for
> a
> > > relative interval are unaffected, but timers for an absolute point
> in
> > > time are affected”. This indicates that the Linux implementation
> of
> > > clock_settime() follows the POSIX specification, as expected. Also
> the
> > > Linux implementation of nanosleep() uses relative timers, as
> expected.
> > > 
> > > However, almost all Linux API functions use absolute timer
> intervals.
> > > For instance, the man page for sem_timedwait() states that the
> timeout
> > > is an absolute interval meaning that it will be affected by clock
> > > changes. Thus, if task A is blocked in a sem_timedwait() call, and
> > > task B moves time forward with clock_settime(), then task A will
> > > return from sem_timedwait() with ETIMEOUT prematurely.
> > > 
> > > From my examination of the documentation on Xenomai, it would
> appear
> > > that Xenomai does not suffer from this problem, but I would like
> to
> > > confirm my impression. My question to this list is, in Xenomai, if
> one
> > > calls rt_sem_p() with a timeout, will that timeout be correct even
> if
> > > a task changes the clock with clock_settime()?
> > > 
> > > Additionally, the documentation of the POSIX skin of Xenomai
> indicates
> > > that sem_timedwait() uses an absolute timeout. So, is the Xenomai
> > > version of sem_timedwait() vulnerable to clock changes? Do I have
> to
> > > use rt_sem_p() in order to avoid issues with clock changes?
> > 
> > 
> > Well, the POSIX behavior just makes sense, the kernel does not have
> to
> > figure out that in fact, your code is not immune to system time
> updates
> > so as to eventually consider absolute timeout specs as being
> relative
> > ones in disguise.
> > 
> > Therefore I would not speak about vulnerability here, it is just how
> > POSIX works, because absolute timeouts do have an advantage over
> > relative timeouts. Since Xenomai's POSIX skin wants to comply with
> the
> > standard, it does resume outstanding timers which end up having a
> > trigger date in the past due to a clock_settime() request.
> > 
> > The native Xenomai skin - which rt_sem_p is part of - has both
> relative
> > and absolute timeout forms. The relative form won't be sensitive to
> > system time updates, whilst the absolute form will. So you may want
> to
> > switch skins, or fix your POSIX code to explicitly deal with this
> issue.
> > YMMV. (I would probably fix my code actually).
> > 
> > > 
> > > Thanks in advance.
> > > Christopher Stone
> > > Optelian, Inc.
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Xenomai-help mailing list
> > > Xenomai-help@domain.hid
> > > https://mail.gna.org/listinfo/xenomai-help
> > 
> > -- 
> > Philippe.
> > 
> > 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

-- 
Philippe.

Re: [Xenomai-help] Xenomai and timers.

[Chris Stone]

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


Phillipe and Gilles, thanks for your help, you guys are awesome.

Cheers,
    Chris.

> Subject: Re: [Xenomai-help] Xenomai and timers.
> From: rpm@xenomai.org
> To: chris.linux@domain.hid
> CC: xenomai@xenomai.org
> Date: Fri, 17 Dec 2010 10:09:47 +0100
> 
> On Thu, 2010-12-16 at 15:30 -0400, Chris Stone wrote:
> > Thanks for your reply, and I realize that I am now getting off topic
> > for this list, but if the explanation is easy perhaps I could impose
> > on you a little further. How does one fix the POSIX code to deal with
> > this issue? When sem_timedwait() returns with ETIMEDOUT, how does one
> > know that the time was changed by another task and the timeout was not
> > the duration that was asked for? 
> 
> I'm excluding small time adjustments, NTP-like, which should not be an
> issue, because timeouts are not for accurate timing, but really for
> implementing a safety belt against infinite hangs, so this is coarse
> grained in essence. I'm talking about large arbitrary leaps forward done
> using clock_settime() from an application context.
> 
> A possible answer then, is two fold:
> 
> - you likely control all the code running on your embedded platform,
> which should include the task(s) issuing clock_settime(). Flagging this
> particular action so that other tasks could detect it later on should be
> possible. It should even be possible to exclude system time updates
> using a rwlock mechanism when other tasks are about to pend on a timed
> sync. Waiters would pick the read side before pending on the sync, the
> task issuing clock_settime() would have to grab the write side before
> changing time. In effect, this might postpone the system time update
> until all waiters have either received the resource or hit a timeout
> condition, but maybe this is acceptable for you.
> 
> - upon ETIMEDOUT condition, if the difference between clock_gettime()
> when returning, and clock_gettime() before sleeping is preposterously
> larger than the specified timeout, then the code may assume a system
> time update took place, and act upon accordingly.  The cost here is one
> syscall more issued unconditionally before entering the timed wait to
> get the current time, but this may be acceptable as well. The grey area
> is for updates in the range of the typical timeout value, you would
> likely have to rely on something like the previous option instead.
> 
> > 
> > Chris.
> > 
> > > Subject: Re: [Xenomai-help] Xenomai and timers.
> > > From: rpm@xenomai.org
> > > To: chris.linux@domain.hid
> > > CC: xenomai@xenomai.org
> > > Date: Thu, 16 Dec 2010 19:40:10 +0100
> > > 
> > > On Thu, 2010-12-16 at 13:55 -0400, Chris Stone wrote:
> > > > I am trying to determine if Xenomai will help me to solve a
> > problem I
> > > > am having with embedded Linux in a real time environment. To set
> > the
> > > > context of the problem I am trying to solve, some background is
> > > > necessary.
> > > > 
> > > > Our application area is telecommunications, we build cards for
> > optical
> > > > transport applications. We have recently transitioned from using
> > Green
> > > > Hills Velocity to embedded Linux as our real time operating
> > system.
> > > > Our applications are complex and multi-tasking and they use
> > standard
> > > > solutions such as semaphores to serialize access to shared data.
> > In
> > > > our first port of the Green Hills Velocity code to embedded Linux
> > we
> > > > often used sem_timedwait() to wait for a semaphore for a bounded
> > > > amount of time. However, Linux appears to have an issue with
> > timers
> > > > when a task changes the clock with clock_settime().
> > > > 
> > > > The POSIX specification for clock_settime() states that: “Setting
> > the
> > > > value of the CLOCK_REALTIME clock via clock_settime() shall have
> > no
> > > > effect on threads that are blocked waiting for a relative time
> > service
> > > > based upon this clock, including the nanosleep() function; nor on
> > the
> > > > expiration of relative timers based upon this clock. Consequently,
> > > > these time services shall expire when the requested relative
> > interval
> > > > elapses, independently of the new or old value of the clock.”
> > > > 
> > > > Additionally, the Linux man page for clock_settime() states that:
> > “All
> > > > implementations support the system-wide realtime clock, which is
> > > > identified by CLOCK_REALTIME. Its time represents seconds and
> > > > nanoseconds since the Epoch. When its time is changed, timers for
> > a
> > > > relative interval are unaffected, but timers for an absolute point
> > in
> > > > time are affected”. This indicates that the Linux implementation
> > of
> > > > clock_settime() follows the POSIX specification, as expected. Also
> > the
> > > > Linux implementation of nanosleep() uses relative timers, as
> > expected.
> > > > 
> > > > However, almost all Linux API functions use absolute timer
> > intervals.
> > > > For instance, the man page for sem_timedwait() states that the
> > timeout
> > > > is an absolute interval meaning that it will be affected by clock
> > > > changes. Thus, if task A is blocked in a sem_timedwait() call, and
> > > > task B moves time forward with clock_settime(), then task A will
> > > > return from sem_timedwait() with ETIMEOUT prematurely.
> > > > 
> > > > From my examination of the documentation on Xenomai, it would
> > appear
> > > > that Xenomai does not suffer from this problem, but I would like
> > to
> > > > confirm my impression. My question to this list is, in Xenomai, if
> > one
> > > > calls rt_sem_p() with a timeout, will that timeout be correct even
> > if
> > > > a task changes the clock with clock_settime()?
> > > > 
> > > > Additionally, the documentation of the POSIX skin of Xenomai
> > indicates
> > > > that sem_timedwait() uses an absolute timeout. So, is the Xenomai
> > > > version of sem_timedwait() vulnerable to clock changes? Do I have
> > to
> > > > use rt_sem_p() in order to avoid issues with clock changes?
> > > 
> > > 
> > > Well, the POSIX behavior just makes sense, the kernel does not have
> > to
> > > figure out that in fact, your code is not immune to system time
> > updates
> > > so as to eventually consider absolute timeout specs as being
> > relative
> > > ones in disguise.
> > > 
> > > Therefore I would not speak about vulnerability here, it is just how
> > > POSIX works, because absolute timeouts do have an advantage over
> > > relative timeouts. Since Xenomai's POSIX skin wants to comply with
> > the
> > > standard, it does resume outstanding timers which end up having a
> > > trigger date in the past due to a clock_settime() request.
> > > 
> > > The native Xenomai skin - which rt_sem_p is part of - has both
> > relative
> > > and absolute timeout forms. The relative form won't be sensitive to
> > > system time updates, whilst the absolute form will. So you may want
> > to
> > > switch skins, or fix your POSIX code to explicitly deal with this
> > issue.
> > > YMMV. (I would probably fix my code actually).
> > > 
> > > > 
> > > > Thanks in advance.
> > > > Christopher Stone
> > > > Optelian, Inc.
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Xenomai-help mailing list
> > > > Xenomai-help@domain.hid
> > > > https://mail.gna.org/listinfo/xenomai-help
> > > 
> > > -- 
> > > Philippe.
> > > 
> > > 
> > _______________________________________________
> > Xenomai-help mailing list
> > Xenomai-help@domain.hid
> > https://mail.gna.org/listinfo/xenomai-help
> 
> -- 
> Philippe.
> 
> 
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 9749 bytes --]

Re: [Xenomai-help] Xenomai and timers.

[Richard Cochran]

On Fri, Dec 17, 2010 at 10:09:47AM +0100, Philippe Gerum wrote:
> grained in essence. I'm talking about large arbitrary leaps forward done
> using clock_settime() from an application context.
> 
> A possible answer then, is two fold:

BTW, there has been some discussion on the lkml recently on the
question, how can a program detect that a clock has been reset?

The latest suggested patch and a summary is at:

   http://article.gmane.org/gmane.linux.kernel/1070389

Richard