Re: [Xenomai-core] Monotonic, realtime, and other timers

2007-06-27 Thread Jan Kiszka
Gilles Chanteperdrix wrote:
 Jan Kiszka wrote:
   Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
  Gilles Chanteperdrix wrote:
   IMO, the only advantage of having absolute timers is to be able to 
 apply
   the posix scheme. So, if I followed correctly your discussion, what 
 we
   need is:
   - an XNTBISOL flag with a service xntbase_isol which set this flag 
 and
 unshare the target timebase if it is shared (IOW, if aperiodic)
   - the service xntbase_adjust_time to walk all the absolute timers 
 of the
 non isolated timebases and adjust their expiry date or play their
 handler the posix way.
  
  Two questions came up here regarding item #2:
  
   - Shouldn't we also adjust the non-monotonic timers of an isolated 
 base
 if it asks for wallclock tuning? I think so.
  
   - We don't have a service to walk the list of all pending timers, do
 we? As that touches all of our timer queue variants and I'm not
 familiar with their details (except for plain lists...), I would
 welcome any support on this.

I am afraid for other things than lists, we will have to define an
xntimerq_iterator which holds a little bit more information than just a
pointer to a holder.

   
   So we would have to increase the size of each xntimer_t object? Argh.
   
   Sounds a bit like it's worth to have a closer look at some two timer
   lists, one with adjustable offset-approach...
 
 No, I was thinking about defining a new type xntimerq_iterator, whose
 sole purpose would be to hold the state of an iteration. In fact, we
 only need this in the hashed case, binary heap holders already contain
 enough information.
 

OK, if that will not have negative impact on existing code, so much the
better.

Meanwhile I uploaded my current patch stack to
http://www.rts.uni-hannover.de/rtaddon/patches/xenomai. I'm going to
comment on detail aspects later. Just so much: it /should/ be finished
except for the yet empty placeholder re-adjust-timers.patch.

Jan



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Monotonic, realtime, and other timers

2007-06-26 Thread Jan Kiszka
Gilles Chanteperdrix wrote:
 IMO, the only advantage of having absolute timers is to be able to apply
 the posix scheme. So, if I followed correctly your discussion, what we
 need is:
 - an XNTBISOL flag with a service xntbase_isol which set this flag and
   unshare the target timebase if it is shared (IOW, if aperiodic)
 - the service xntbase_adjust_time to walk all the absolute timers of the
   non isolated timebases and adjust their expiry date or play their
   handler the posix way.

Two questions came up here regarding item #2:

 - Shouldn't we also adjust the non-monotonic timers of an isolated base
   if it asks for wallclock tuning? I think so.

 - We don't have a service to walk the list of all pending timers, do
   we? As that touches all of our timer queue variants and I'm not
   familiar with their details (except for plain lists...), I would
   welcome any support on this.

Jan



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Monotonic, realtime, and other timers

2007-06-26 Thread Gilles Chanteperdrix
Jan Kiszka wrote:
  Gilles Chanteperdrix wrote:
   IMO, the only advantage of having absolute timers is to be able to apply
   the posix scheme. So, if I followed correctly your discussion, what we
   need is:
   - an XNTBISOL flag with a service xntbase_isol which set this flag and
 unshare the target timebase if it is shared (IOW, if aperiodic)
   - the service xntbase_adjust_time to walk all the absolute timers of the
 non isolated timebases and adjust their expiry date or play their
 handler the posix way.
  
  Two questions came up here regarding item #2:
  
   - Shouldn't we also adjust the non-monotonic timers of an isolated base
 if it asks for wallclock tuning? I think so.
  
   - We don't have a service to walk the list of all pending timers, do
 we? As that touches all of our timer queue variants and I'm not
 familiar with their details (except for plain lists...), I would
 welcome any support on this.

I am afraid for other things than lists, we will have to define an
xntimerq_iterator which holds a little bit more information than just a
pointer to a holder.

-- 


Gilles Chanteperdrix.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Monotonic, realtime, and other timers

2007-06-26 Thread Philippe Gerum
On Tue, 2007-06-26 at 15:39 +0200, Jan Kiszka wrote:
 Gilles Chanteperdrix wrote:
  IMO, the only advantage of having absolute timers is to be able to apply
  the posix scheme. So, if I followed correctly your discussion, what we
  need is:
  - an XNTBISOL flag with a service xntbase_isol which set this flag and
unshare the target timebase if it is shared (IOW, if aperiodic)
  - the service xntbase_adjust_time to walk all the absolute timers of the
non isolated timebases and adjust their expiry date or play their
handler the posix way.
 
 Two questions came up here regarding item #2:
 
  - Shouldn't we also adjust the non-monotonic timers of an isolated base
if it asks for wallclock tuning? I think so.

When xntbase_adjust_time() is called for an isolated timebase, we want
the real-time timers to be checked for immediate expiry against the new
epoch, and fire those who happen to have suddently elapsed.

 
  - We don't have a service to walk the list of all pending timers, do
we? As that touches all of our timer queue variants and I'm not
familiar with their details (except for plain lists...), I would
welcome any support on this.
 
 Jan
 
-- 
Philippe.



___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Monotonic, realtime, and other timers

2007-06-26 Thread Jan Kiszka
Gilles Chanteperdrix wrote:
 Jan Kiszka wrote:
   Gilles Chanteperdrix wrote:
IMO, the only advantage of having absolute timers is to be able to apply
the posix scheme. So, if I followed correctly your discussion, what we
need is:
- an XNTBISOL flag with a service xntbase_isol which set this flag and
  unshare the target timebase if it is shared (IOW, if aperiodic)
- the service xntbase_adjust_time to walk all the absolute timers of the
  non isolated timebases and adjust their expiry date or play their
  handler the posix way.
   
   Two questions came up here regarding item #2:
   
- Shouldn't we also adjust the non-monotonic timers of an isolated base
  if it asks for wallclock tuning? I think so.
   
- We don't have a service to walk the list of all pending timers, do
  we? As that touches all of our timer queue variants and I'm not
  familiar with their details (except for plain lists...), I would
  welcome any support on this.
 
 I am afraid for other things than lists, we will have to define an
 xntimerq_iterator which holds a little bit more information than just a
 pointer to a holder.
 

So we would have to increase the size of each xntimer_t object? Argh.

Sounds a bit like it's worth to have a closer look at some two timer
lists, one with adjustable offset-approach...

Jan



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Monotonic, realtime, and other timers

2007-06-26 Thread Gilles Chanteperdrix
Jan Kiszka wrote:
  Gilles Chanteperdrix wrote:
   Jan Kiszka wrote:
 Gilles Chanteperdrix wrote:
  IMO, the only advantage of having absolute timers is to be able to 
   apply
  the posix scheme. So, if I followed correctly your discussion, what we
  need is:
  - an XNTBISOL flag with a service xntbase_isol which set this flag and
unshare the target timebase if it is shared (IOW, if aperiodic)
  - the service xntbase_adjust_time to walk all the absolute timers of 
   the
non isolated timebases and adjust their expiry date or play their
handler the posix way.
 
 Two questions came up here regarding item #2:
 
  - Shouldn't we also adjust the non-monotonic timers of an isolated base
if it asks for wallclock tuning? I think so.
 
  - We don't have a service to walk the list of all pending timers, do
we? As that touches all of our timer queue variants and I'm not
familiar with their details (except for plain lists...), I would
welcome any support on this.
   
   I am afraid for other things than lists, we will have to define an
   xntimerq_iterator which holds a little bit more information than just a
   pointer to a holder.
   
  
  So we would have to increase the size of each xntimer_t object? Argh.
  
  Sounds a bit like it's worth to have a closer look at some two timer
  lists, one with adjustable offset-approach...

No, I was thinking about defining a new type xntimerq_iterator, whose
sole purpose would be to hold the state of an iteration. In fact, we
only need this in the hashed case, binary heap holders already contain
enough information.

-- 


Gilles Chanteperdrix.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Monotonic, realtime, and other timers

2007-06-25 Thread Gilles Chanteperdrix
Jan Kiszka wrote:
  Ok, I think it's time to summarise some results of this thread:
  
   - xntimers will be of three kinds: real-time absolute, monotonic
 absolute, and monotonic relative ones (ie. all POSIX). I'm currently
 in favour of passing this property on timer start and not pushing
 parts or more of it into timer init.

The posix skin can live without monotonic absolute timers: monotonic
timeout could simply be converted to relative timeouts.

-- 


Gilles Chanteperdrix.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Monotonic, realtime, and other timers

2007-06-25 Thread Jan Kiszka
Gilles Chanteperdrix wrote:
 Jan Kiszka wrote:
   Ok, I think it's time to summarise some results of this thread:
   
- xntimers will be of three kinds: real-time absolute, monotonic
  absolute, and monotonic relative ones (ie. all POSIX). I'm currently
  in favour of passing this property on timer start and not pushing
  parts or more of it into timer init.
 
 The posix skin can live without monotonic absolute timers: monotonic
 timeout could simply be converted to relative timeouts.
 

The POSIX skin will not be the only user, and I rather see disadvantages
/wrt the hot-path (multiple timer readouts + conversions) when moving
over emulation mode again.

Anyway, I hope I can come up with some patches over the next days,
clarifying what we actually need to change (not much I think).

Jan



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Monotonic, realtime, and other timers

2007-06-25 Thread Jan Kiszka
Jan Kiszka wrote:
 Gilles Chanteperdrix wrote:
 Jan Kiszka wrote:
   Ok, I think it's time to summarise some results of this thread:
   
- xntimers will be of three kinds: real-time absolute, monotonic
  absolute, and monotonic relative ones (ie. all POSIX). I'm currently
  in favour of passing this property on timer start and not pushing
  parts or more of it into timer init.

 The posix skin can live without monotonic absolute timers: monotonic
 timeout could simply be converted to relative timeouts.

 
 The POSIX skin will not be the only user, and I rather see disadvantages
 /wrt the hot-path (multiple timer readouts + conversions) when moving
 over emulation mode again.
 
 Anyway, I hope I can come up with some patches over the next days,
 clarifying what we actually need to change (not much I think).

Here is a first draft of a (hopefully final) xntimer_start API change.
Well, it does have some impact on this new interface and its users (but
those will need individual review anyway). So please let me know if you
think I'm on the right track -- before I generate useless changes.

Note: This snippet does not yet address isolated time bases or
re-adjustments of running timers with XNTIMER_REALTIME set. But that
will be straightforward then. Likely...

Jan


Index: xenomai/include/nucleus/timer.h
===
--- xenomai.orig/include/nucleus/timer.h
+++ xenomai/include/nucleus/timer.h
@@ -35,7 +35,9 @@
 #define XNTIMER_DEQUEUED  0x0001
 #define XNTIMER_KILLED0x0002
 #define XNTIMER_PERIODIC  0x0004
-#define XNTIMER_MONOTONIC 0x0008
+#define XNTIMER_REALTIME  0x0008
+
+#define XNTIMER_ABSOLUTE  0x0010 /* only used for timer start */
 
 /* These flags are available to the real-time interfaces */
 #define XNTIMER_SPARE0  0x0100
@@ -47,6 +49,14 @@
 #define XNTIMER_SPARE6  0x4000
 #define XNTIMER_SPARE7  0x8000
 
+/* Timer operation modes */
+typedef enum xntimer_mode {
+   XNTM_MONOREL = 0,
+   XNTM_MONOABS = XNTIMER_ABSOLUTE,
+   XNTM_REALABS = XNTIMER_REALTIME | XNTIMER_ABSOLUTE
+} xntimer_mode_t;
+
+/* Timer priorities */
 #define XNTIMER_LOPRIO  (-9)
 #define XNTIMER_STDPRIO 0
 #define XNTIMER_HIPRIO  9
@@ -284,10 +294,6 @@ typedef struct xntimed_slave {
 #endif /* !CONFIG_SMP */
 #define xntimer_interval(t)((t)-interval)
 #define xntimer_set_cookie(t,c)((t)-cookie = (c))
-#define xntimer_set_monotonic(t) \
-   __setbits((t)-status, XNTIMER_MONOTONIC)
-#define xntimer_set_realtime(t) \
-   __clrbits((t)-status, XNTIMER_MONOTONIC)
 
 #ifdef CONFIG_XENO_OPT_TIMING_PERIODIC
 #define xntimer_base(t)((t)-base)
@@ -409,7 +415,7 @@ static inline void xntimer_set_name(xnti
 
 static inline int xntimer_start(xntimer_t *timer,
xnticks_t value, xnticks_t interval,
-   int mode)
+   xntimer_mode_t mode)
 {
return timer-base-ops-start_timer(timer, value, interval, mode);
 }
@@ -590,7 +596,7 @@ void xntslave_stop(xntslave_t *slave);
 int xntimer_start_aperiodic(xntimer_t *timer,
xnticks_t value,
xnticks_t interval,
-   int mode);
+   xntimer_mode_t mode);
 
 void xntimer_stop_aperiodic(xntimer_t *timer);
 
@@ -604,7 +610,7 @@ xnticks_t xntimer_get_raw_expiry_aperiod
 
 static inline int xntimer_start(xntimer_t *timer,
xnticks_t value, xnticks_t interval,
-   int mode)
+   xntimer_mode_t mode)
 {
return xntimer_start_aperiodic(timer, value, interval, mode);
 }
Index: xenomai/include/nucleus/types.h
===
--- xenomai.orig/include/nucleus/types.h
+++ xenomai/include/nucleus/types.h
@@ -62,8 +62,6 @@ typedef int (*xniack_t)(unsigned irq);
 
 #define XN_INFINITE   (0)
 #define XN_NONBLOCK   ((xnticks_t)-1)
-#define XN_RELATIVE   0
-#define XN_ABSOLUTE   1
 
 #define XN_APERIODIC_TICK  0
 #define XN_NO_TICK ((xnticks_t)-1)
Index: xenomai/ksrc/nucleus/timer.c
===
--- xenomai.orig/ksrc/nucleus/timer.c
+++ xenomai/ksrc/nucleus/timer.c
@@ -91,7 +91,7 @@ static inline void xntimer_next_remote_s
 
 int xntimer_start_aperiodic(xntimer_t *timer,
xnticks_t value, xnticks_t interval,
-   int mode)
+   xntimer_mode_t mode)
 {
xnticks_t date, now;
 
@@ -100,14 +100,20 @@ int xntimer_start_aperiodic(xntimer_t *t
 
now = xnarch_get_cpu_tsc();
 
-   if (mode == XN_RELATIVE)
+   switch (mode) {
+   case XNTM_MONOREL:
date = xnarch_ns_to_tsc(value) + now;
-   else {
-   if (!testbits(timer-status, 

Re: [Xenomai-core] Monotonic, realtime, and other timers

2007-06-25 Thread Gilles Chanteperdrix
Jan Kiszka wrote:
  +/* Timer operation modes */
  +typedef enum xntimer_mode {
  +XNTM_MONOREL = 0,
  +XNTM_MONOABS = XNTIMER_ABSOLUTE,
  +XNTM_REALABS = XNTIMER_REALTIME | XNTIMER_ABSOLUTE
  +} xntimer_mode_t;

Is not it a bit weird to use enums ? I meanç we use #defines everywhere
else.

  +default: /* XNTM_MONOABS || XNTM_REALABS */
   date = xnarch_ns_to_tsc(value);
   if (date = now)
   return -ETIMEDOUT;
  +__setbits(timer-status, XNTIMER_REALTIME);
  +break;

Having the same treatment for absolute monotonic and realtime clocks
looks suspicious.


  +default: /* XNTM_MONOABS || XNTM_REALABS */
   if (value = timer-base-jiffies)
   return -ETIMEDOUT;
  +__setbits(timer-status, XNTIMER_REALTIME);
  +break;

Same here


-- 


Gilles Chanteperdrix.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Monotonic, realtime, and other timers

2007-06-25 Thread Jan Kiszka
Gilles Chanteperdrix wrote:
 Jan Kiszka wrote:
   +/* Timer operation modes */
   +typedef enum xntimer_mode {
   +  XNTM_MONOREL = 0,
   +  XNTM_MONOABS = XNTIMER_ABSOLUTE,
   +  XNTM_REALABS = XNTIMER_REALTIME | XNTIMER_ABSOLUTE
   +} xntimer_mode_t;
 
 Is not it a bit weird to use enums ? I meanç we use #defines everywhere
 else.

I'm starting to like these kind of types, because they express what
values are expected and allowed here. Anyway, if this is not desired, I
can use plain defines again as well.

 
   +  default: /* XNTM_MONOABS || XNTM_REALABS */
  date = xnarch_ns_to_tsc(value);
  if (date = now)
  return -ETIMEDOUT;
   +  __setbits(timer-status, XNTIMER_REALTIME);
   +  break;
 
 Having the same treatment for absolute monotonic and realtime clocks
 looks suspicious.

Nope, please have a look at the two line above this excerpt, they should
explain the difference.

 
 
   +  default: /* XNTM_MONOABS || XNTM_REALABS */
  if (value = timer-base-jiffies)
  return -ETIMEDOUT;
   +  __setbits(timer-status, XNTIMER_REALTIME);
   +  break;
 
 Same here
 
 

Thanks for a having a view,

Jan



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Monotonic, realtime, and other timers

2007-06-25 Thread Philippe Gerum
On Mon, 2007-06-25 at 08:12 +0200, Jan Kiszka wrote:
 Ok, I think it's time to summarise some results of this thread:
 
  - xntimers will be of three kinds: real-time absolute, monotonic
absolute, and monotonic relative ones (ie. all POSIX). I'm currently
in favour of passing this property on timer start and not pushing
parts or more of it into timer init.

I will probably experiment this change in the course of x3-devel anyway,
we'll see what we get from it then.

 
  - XNTBISOL will be introduced, a flag that, if set, declares a time
base being isolated from the master base (and associates). In my
understanding, this flag should be passed to xntbase_alloc and should
also leave the wallclock offset initially untouched again.
 
  - On xntbase_adjust_time, first define the set of affected time bases:
if XNTBISOL is set, only touch the passed base, if it is not set,
change all bases in the system that have it cleared as well. For this
set of time bases, modify the offset and adjust all running real-time
timers.
 
  - Make all legacy RTOS skins isolated by default again, but offer a
runtime or compile-time switch to add them individually to the gang
of synchronised time bases (i.e. POSIX, native, RTDM).
 
 Did I get it correctly?
 

Looks good. Regarding the monotonic support, I tend to agree with you:
let's avoid conversions especially if doing so is cheap
implementation-wise.

 Jan
 
-- 
Philippe.



___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Monotonic, realtime, and other timers

2007-06-24 Thread Jan Kiszka
Philippe Gerum wrote:
 On Sat, 2007-06-23 at 13:39 +0200, Jan Kiszka wrote:
 Philippe Gerum wrote:
 On Sat, 2007-06-23 at 10:08 +0200, Jan Kiszka wrote:
 Hi,

 [just to save this early-Saturday-morning insight]

 I think the xntimer interface is not yet ready to represent all required
 scenarios. What kind of timers are there? Let's start with POSIX:

 1. Realtime timers - use realtime clock as base, re-tune
  absolute(!) expiry dates if the realtime clock
  changes
 2. Monotonic timers- use monotonic clock as base, don't re-adjust
  during runtime

 Now what we have in current trunk:

 3a. Realtime xntimers  - use wallclock_offset to calculate absolute
  expiry dates, don't re-adjust during runtime
 4a. Monotonic xntimers - use raw jiffies/TSC as base, don't re-adjust
  during runtime

 And this is what we planed to introduce soon:

 3b. Realtime xntimers  - use wallclock offset to calculate absolute
  expiry dates, re-adjust if the offset changes
  during runtime
 I merged this patch already, so this issue becomes top-ranked on the fix
 list.
 Nope, you didn't. We only discussed 3b on Thursday, we still have 3a in
 place (i.e. no running timer is re-adjusted on xntbase_adjust_time). But
 we will need this for POSIX compliance.

 
 Sorry, my mistake. I was thinking about timebase readjustment, which
 patch I did merge, while you were talking about timer readjustement,
 which code is not there yet anyway.
 
 4b. Monotonic xntimers - same as 4a

 3b and 4b almost perfectly match POSIX, one only has to pass relative
 realtime timers as monotonic ones (Linux does so too). But there are a
 lot of skins that potentially rely on 3a!
 They do, but not only on the timer issue, but this also has an impact on
 the time unit used to return the current time. I must admit that this is
 becoming a mess.
 Leaving Native apart for a while (though this doesn't mean we should
 break its API):
 
 No doubt about this. But the native skin is particular in the sense that
 it does not provide any service to change its own epoch, so one may
 assume that it directly depends on the global epoch defined by the
 nucleus, and as such, may be subject to immediate timer expiry in case
 the wallclock offset is globally updated. AFAICS, only
 rt_task_sleep_until() and rt_task_set_periodic() would be impacted.

Yes, looks like. So you think we could migrate Native over the POSIX
scheme just by clarifying the docs? Hmm, could work.

 
  Are there also legacy RTOS skins around that rely on a
 timer property set timeout according to current wallclock, but don't
 touch it anymore once it was started?

 
 There are legacy RTOS which have both the notions of absolute timeouts
 and also define a mechanism to setup their own epoch: those would be
 impacted by the pending changes on the nucleus timer management. In that
 case, the virtual RTOS machine should be isolated from propagation of
 wallclock offset changes from other parts of the Xenomai system.
 
 E.g. VRTX's sc_adelay service which is currently emulated using a
 relative delay, but should in fact be using an absolute timeout since
 there is a service to change the epoch in this interface (sc_sclock).
 Actually, it looks like each and every skin should be inspected for
 conformance again wrt time management once the dust has settled on the
 timebase and timer related changes (pSOS would be next).
 
 Actually, this wouldn't be a mess then, it would just derive from
 Xenomai aiming at emulating all the available timer variants on the
 market. And this may come at the price of slightly increase complexity
 (but not necessarily worse than the current code, ie. acceptable IMO).

 
 As illustrated by the VRTX code, what makes the situation messy in my
 eyes is that some skins used to work around the nucleus limitations in
 terms of time management (lack of built-in absolute timing support, no
 timebases, no strictly monotonic absolute timing), but those hacks tend
 to bite us now that we do have / are in the process of having proper
 support at nucleus level.
 
 The other issue regarding legacy RTOS emulation, is that they should not
 be impacted by the wallclock offset at all, when they deal with jiffies.
 E.g. in the VRTX case, we should always have something behaving like
 this:
 
 sc_stime(8129)
 ...
 ...(work for 11 VRTX ticks)
 ...
 ticks = sc_gtime(); /* ticks == 8140 */
 
 If sc_stime() is not called to set the epoch for the VRTX timebase, then
 0 would be assumed for the epoch, and 11 returned by the sc_gtime()
 call.
 In any case, starting the timebase, or having another skin propagate a
 wallclock offset change in parallel should never impact the VRTX machine
 time. The reason is that some application code might do some weird
 arithmetics on tick deltas, but also on the raw VRTX clock value for
 internal purpose, and 

Re: [Xenomai-core] Monotonic, realtime, and other timers

2007-06-24 Thread Gilles Chanteperdrix

IMO, the only advantage of having absolute timers is to be able to apply
the posix scheme. So, if I followed correctly your discussion, what we
need is:
- an XNTBISOL flag with a service xntbase_isol which set this flag and
  unshare the target timebase if it is shared (IOW, if aperiodic)
- the service xntbase_adjust_time to walk all the absolute timers of the
  non isolated timebases and adjust their expiry date or play their
  handler the posix way.

-- 


Gilles Chanteperdrix.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Monotonic, realtime, and other timers

2007-06-24 Thread Philippe Gerum
On Sun, 2007-06-24 at 10:43 +0200, Jan Kiszka wrote: 
 Philippe Gerum wrote:
  On Sat, 2007-06-23 at 13:39 +0200, Jan Kiszka wrote:
  Philippe Gerum wrote:
  On Sat, 2007-06-23 at 10:08 +0200, Jan Kiszka wrote:
  Hi,
 
  [just to save this early-Saturday-morning insight]
 
  I think the xntimer interface is not yet ready to represent all required
  scenarios. What kind of timers are there? Let's start with POSIX:
 
  1. Realtime timers   - use realtime clock as base, re-tune
 absolute(!) expiry dates if the realtime clock
 changes
  2. Monotonic timers  - use monotonic clock as base, don't re-adjust
 during runtime
 
  Now what we have in current trunk:
 
  3a. Realtime xntimers- use wallclock_offset to calculate absolute
 expiry dates, don't re-adjust during runtime
  4a. Monotonic xntimers   - use raw jiffies/TSC as base, don't re-adjust
 during runtime
 
  And this is what we planed to introduce soon:
 
  3b. Realtime xntimers- use wallclock offset to calculate absolute
 expiry dates, re-adjust if the offset changes
 during runtime
  I merged this patch already, so this issue becomes top-ranked on the fix
  list.
  Nope, you didn't. We only discussed 3b on Thursday, we still have 3a in
  place (i.e. no running timer is re-adjusted on xntbase_adjust_time). But
  we will need this for POSIX compliance.
 
  
  Sorry, my mistake. I was thinking about timebase readjustment, which
  patch I did merge, while you were talking about timer readjustement,
  which code is not there yet anyway.
  
  4b. Monotonic xntimers   - same as 4a
 
  3b and 4b almost perfectly match POSIX, one only has to pass relative
  realtime timers as monotonic ones (Linux does so too). But there are a
  lot of skins that potentially rely on 3a!
  They do, but not only on the timer issue, but this also has an impact on
  the time unit used to return the current time. I must admit that this is
  becoming a mess.
  Leaving Native apart for a while (though this doesn't mean we should
  break its API):
  
  No doubt about this. But the native skin is particular in the sense that
  it does not provide any service to change its own epoch, so one may
  assume that it directly depends on the global epoch defined by the
  nucleus, and as such, may be subject to immediate timer expiry in case
  the wallclock offset is globally updated. AFAICS, only
  rt_task_sleep_until() and rt_task_set_periodic() would be impacted.
 
 Yes, looks like. So you think we could migrate Native over the POSIX
 scheme just by clarifying the docs? Hmm, could work.

I would not hesitate a second to change this API if it ought to work
differently, but fact is that POSIX behaviour in case the epoch changes
is logically speaking the only one that fits. If we only have to make
the doc explicit about that, fine, but that's not the main issue.

 
  
   Are there also legacy RTOS skins around that rely on a
  timer property set timeout according to current wallclock, but don't
  touch it anymore once it was started?
 
  
  There are legacy RTOS which have both the notions of absolute timeouts
  and also define a mechanism to setup their own epoch: those would be
  impacted by the pending changes on the nucleus timer management. In that
  case, the virtual RTOS machine should be isolated from propagation of
  wallclock offset changes from other parts of the Xenomai system.
  
  E.g. VRTX's sc_adelay service which is currently emulated using a
  relative delay, but should in fact be using an absolute timeout since
  there is a service to change the epoch in this interface (sc_sclock).
  Actually, it looks like each and every skin should be inspected for
  conformance again wrt time management once the dust has settled on the
  timebase and timer related changes (pSOS would be next).
  
  Actually, this wouldn't be a mess then, it would just derive from
  Xenomai aiming at emulating all the available timer variants on the
  market. And this may come at the price of slightly increase complexity
  (but not necessarily worse than the current code, ie. acceptable IMO).
 
  
  As illustrated by the VRTX code, what makes the situation messy in my
  eyes is that some skins used to work around the nucleus limitations in
  terms of time management (lack of built-in absolute timing support, no
  timebases, no strictly monotonic absolute timing), but those hacks tend
  to bite us now that we do have / are in the process of having proper
  support at nucleus level.
  
  The other issue regarding legacy RTOS emulation, is that they should not
  be impacted by the wallclock offset at all, when they deal with jiffies.
  E.g. in the VRTX case, we should always have something behaving like
  this:
  
  sc_stime(8129)
  ...
  ...(work for 11 VRTX ticks)
  ...
  ticks = sc_gtime(); /* ticks == 8140 */
  
  If sc_stime() is not called to set the 

Re: [Xenomai-core] Monotonic, realtime, and other timers

2007-06-23 Thread Philippe Gerum
On Sat, 2007-06-23 at 10:08 +0200, Jan Kiszka wrote:
 Hi,
 
 [just to save this early-Saturday-morning insight]
 
 I think the xntimer interface is not yet ready to represent all required
 scenarios. What kind of timers are there? Let's start with POSIX:
 
 1. Realtime timers- use realtime clock as base, re-tune
 absolute(!) expiry dates if the realtime clock
 changes
 2. Monotonic timers   - use monotonic clock as base, don't re-adjust
 during runtime
 
 Now what we have in current trunk:
 
 3a. Realtime xntimers - use wallclock_offset to calculate absolute
 expiry dates, don't re-adjust during runtime
 4a. Monotonic xntimers- use raw jiffies/TSC as base, don't re-adjust
 during runtime
 
 And this is what we planed to introduce soon:
 
 3b. Realtime xntimers - use wallclock offset to calculate absolute
 expiry dates, re-adjust if the offset changes
 during runtime

I merged this patch already, so this issue becomes top-ranked on the fix
list.

 4b. Monotonic xntimers- same as 4a
 
 3b and 4b almost perfectly match POSIX, one only has to pass relative
 realtime timers as monotonic ones (Linux does so too). But there are a
 lot of skins that potentially rely on 3a!

They do, but not only on the timer issue, but this also has an impact on
the time unit used to return the current time. I must admit that this is
becoming a mess.

  At least the whole native
 skin, I would say. So we may actually need two knobs when starting an
 xntimer:
 
  A) Take wallclock offset into account when calculating internal expiry
 date?
  B) Re-tune the expiry date during runtime if the offset changes?
 
 Reasonable combinations are none of both (POSIX monotonic), A
 (Xenomai realtime), and A+B (POSIX realtime). Am I right? Please
 comment.

Sorry, -ENOPARSE. Which is the alternative here?

 
 Moreover, it looks to me like the monotonic API I introduced is not very
 handy (fortunately, there is no in-tree user yet). It has a sticky
 property, i.e. you set a persistent flag in the xntimer object if it
 ought to be monotonic. As xntimer structures are typically also
 persistent, you easily end up saving the current mode, setting your own,
 and restoring the old one once the timer fired -- to keep other users of
 the timer happy. E.g., think of RTDM doing some monotonic timing with a
 task while the owning skin may prefer realtime mode. I'm almost
 convinced now that passing a non-sticky mode on each xntimer_start
 (along with XN_ABSOLUTE/RELATIVE in the same parameter) will be more useful.
 

This issue seems orthogonal to the more fundamental one: in which case
does RTDM need to recycle and _change_ the behaviour of timers owned by
other layers? A simple (code) illustration would help understanding the
issue, which is likely RTDM-specific, due to the transverse aspect of
this interface.

 Jan
 
-- 
Philippe.



___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Monotonic, realtime, and other timers

2007-06-23 Thread Jan Kiszka
Philippe Gerum wrote:
 On Sat, 2007-06-23 at 10:08 +0200, Jan Kiszka wrote:
 Hi,

 [just to save this early-Saturday-morning insight]

 I think the xntimer interface is not yet ready to represent all required
 scenarios. What kind of timers are there? Let's start with POSIX:

 1. Realtime timers   - use realtime clock as base, re-tune
absolute(!) expiry dates if the realtime clock
changes
 2. Monotonic timers  - use monotonic clock as base, don't re-adjust
during runtime

 Now what we have in current trunk:

 3a. Realtime xntimers- use wallclock_offset to calculate absolute
expiry dates, don't re-adjust during runtime
 4a. Monotonic xntimers   - use raw jiffies/TSC as base, don't re-adjust
during runtime

 And this is what we planed to introduce soon:

 3b. Realtime xntimers- use wallclock offset to calculate absolute
expiry dates, re-adjust if the offset changes
during runtime
 
 I merged this patch already, so this issue becomes top-ranked on the fix
 list.

Nope, you didn't. We only discussed 3b on Thursday, we still have 3a in
place (i.e. no running timer is re-adjusted on xntbase_adjust_time). But
we will need this for POSIX compliance.

 
 4b. Monotonic xntimers   - same as 4a

 3b and 4b almost perfectly match POSIX, one only has to pass relative
 realtime timers as monotonic ones (Linux does so too). But there are a
 lot of skins that potentially rely on 3a!
 
 They do, but not only on the timer issue, but this also has an impact on
 the time unit used to return the current time. I must admit that this is
 becoming a mess.

Leaving Native apart for a while (though this doesn't mean we should
break its API): Are there also legacy RTOS skins around that rely on a
timer property set timeout according to current wallclock, but don't
touch it anymore once it was started?

Actually, this wouldn't be a mess then, it would just derive from
Xenomai aiming at emulating all the available timer variants on the
market. And this may come at the price of slightly increase complexity
(but not necessarily worse than the current code, ie. acceptable IMO).

 
  At least the whole native
 skin, I would say. So we may actually need two knobs when starting an
 xntimer:

  A) Take wallclock offset into account when calculating internal expiry
 date?
  B) Re-tune the expiry date during runtime if the offset changes?

 Reasonable combinations are none of both (POSIX monotonic), A
 (Xenomai realtime), and A+B (POSIX realtime). Am I right? Please
 comment.
 
 Sorry, -ENOPARSE. Which is the alternative here?

Forgetting about variant A only, ie. potentially breaking existing
stuff for the sake of POSIX and only POSIX. But I don't think this is
acceptable, we need xntimer to support all three as soon as some skin
cries for variant A only.

 
 Moreover, it looks to me like the monotonic API I introduced is not very
 handy (fortunately, there is no in-tree user yet). It has a sticky
 property, i.e. you set a persistent flag in the xntimer object if it
 ought to be monotonic. As xntimer structures are typically also
 persistent, you easily end up saving the current mode, setting your own,
 and restoring the old one once the timer fired -- to keep other users of
 the timer happy. E.g., think of RTDM doing some monotonic timing with a
 task while the owning skin may prefer realtime mode. I'm almost
 convinced now that passing a non-sticky mode on each xntimer_start
 (along with XN_ABSOLUTE/RELATIVE in the same parameter) will be more useful.

 
 This issue seems orthogonal to the more fundamental one: in which case
 does RTDM need to recycle and _change_ the behaviour of timers owned by
 other layers? A simple (code) illustration would help understanding the
 issue, which is likely RTDM-specific, due to the transverse aspect of
 this interface.

I can't tell for sure yet if there are _real_ scenarios where RTDM may
want to switch the xnthread rtimer to monotonic while it is in some
realtime mode, I still need to meditate on this. It's just the strong
_feeling_ that it is cleaner to define the behaviour on start and not on
timer init or via a sticky flag.

Same goes for POSIX I think. You may call clock_nanosleep e.g. with
different clock IDs for the same thread. Currently, all timeouts are
converted before the timer is started. But if we put reasonable logic
into the generic code, those special treatment may be obsolete. Maybe
Gilles has some ideas on how the timer interface (which influences also
xnpod_suspend_thread etc.) might optimally look like for this.

Jan



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Monotonic, realtime, and other timers

2007-06-23 Thread Philippe Gerum
On Sat, 2007-06-23 at 13:39 +0200, Jan Kiszka wrote:
 Philippe Gerum wrote:
  On Sat, 2007-06-23 at 10:08 +0200, Jan Kiszka wrote:
  Hi,
 
  [just to save this early-Saturday-morning insight]
 
  I think the xntimer interface is not yet ready to represent all required
  scenarios. What kind of timers are there? Let's start with POSIX:
 
  1. Realtime timers - use realtime clock as base, re-tune
   absolute(!) expiry dates if the realtime clock
   changes
  2. Monotonic timers- use monotonic clock as base, don't re-adjust
   during runtime
 
  Now what we have in current trunk:
 
  3a. Realtime xntimers  - use wallclock_offset to calculate absolute
   expiry dates, don't re-adjust during runtime
  4a. Monotonic xntimers - use raw jiffies/TSC as base, don't re-adjust
   during runtime
 
  And this is what we planed to introduce soon:
 
  3b. Realtime xntimers  - use wallclock offset to calculate absolute
   expiry dates, re-adjust if the offset changes
   during runtime
  
  I merged this patch already, so this issue becomes top-ranked on the fix
  list.
 
 Nope, you didn't. We only discussed 3b on Thursday, we still have 3a in
 place (i.e. no running timer is re-adjusted on xntbase_adjust_time). But
 we will need this for POSIX compliance.
 

Sorry, my mistake. I was thinking about timebase readjustment, which
patch I did merge, while you were talking about timer readjustement,
which code is not there yet anyway.

  
  4b. Monotonic xntimers - same as 4a
 
  3b and 4b almost perfectly match POSIX, one only has to pass relative
  realtime timers as monotonic ones (Linux does so too). But there are a
  lot of skins that potentially rely on 3a!
  
  They do, but not only on the timer issue, but this also has an impact on
  the time unit used to return the current time. I must admit that this is
  becoming a mess.
 
 Leaving Native apart for a while (though this doesn't mean we should
 break its API):

No doubt about this. But the native skin is particular in the sense that
it does not provide any service to change its own epoch, so one may
assume that it directly depends on the global epoch defined by the
nucleus, and as such, may be subject to immediate timer expiry in case
the wallclock offset is globally updated. AFAICS, only
rt_task_sleep_until() and rt_task_set_periodic() would be impacted.

  Are there also legacy RTOS skins around that rely on a
 timer property set timeout according to current wallclock, but don't
 touch it anymore once it was started?
 

There are legacy RTOS which have both the notions of absolute timeouts
and also define a mechanism to setup their own epoch: those would be
impacted by the pending changes on the nucleus timer management. In that
case, the virtual RTOS machine should be isolated from propagation of
wallclock offset changes from other parts of the Xenomai system.

E.g. VRTX's sc_adelay service which is currently emulated using a
relative delay, but should in fact be using an absolute timeout since
there is a service to change the epoch in this interface (sc_sclock).
Actually, it looks like each and every skin should be inspected for
conformance again wrt time management once the dust has settled on the
timebase and timer related changes (pSOS would be next).

 Actually, this wouldn't be a mess then, it would just derive from
 Xenomai aiming at emulating all the available timer variants on the
 market. And this may come at the price of slightly increase complexity
 (but not necessarily worse than the current code, ie. acceptable IMO).
 

As illustrated by the VRTX code, what makes the situation messy in my
eyes is that some skins used to work around the nucleus limitations in
terms of time management (lack of built-in absolute timing support, no
timebases, no strictly monotonic absolute timing), but those hacks tend
to bite us now that we do have / are in the process of having proper
support at nucleus level.

The other issue regarding legacy RTOS emulation, is that they should not
be impacted by the wallclock offset at all, when they deal with jiffies.
E.g. in the VRTX case, we should always have something behaving like
this:

sc_stime(8129)
...
...(work for 11 VRTX ticks)
...
ticks = sc_gtime(); /* ticks == 8140 */

If sc_stime() is not called to set the epoch for the VRTX timebase, then
0 would be assumed for the epoch, and 11 returned by the sc_gtime()
call.
In any case, starting the timebase, or having another skin propagate a
wallclock offset change in parallel should never impact the VRTX machine
time. The reason is that some application code might do some weird
arithmetics on tick deltas, but also on the raw VRTX clock value for
internal purpose, and touching the epoch under its feet would break such
code.

  
   At least the whole native
  skin, I would say. So we may actually need two knobs when