[Xenomai-core] Towards periodic mode over aperiodic timers

[Xenomai-core] Towards periodic mode over aperiodic timers

[Jan Kiszka]

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

Hi,

the conflict between skins preferring aperiodic timing vs. skin
requiring periodic mode popped up once again on xenomai-help. One way
out of this, likely THE way, is to map such tick-driven skins on a
periodic timer over aperiodic mode (and drop periodic low-level support
completely at the same time).

Let's start some discussion how this can be done, specifically as Gilles
and I are already turning the xntimer subsystem upside down (almost). If
we want co-existence of high-res timing of, say, the posix skin while
the vxworks skin runs over a tick-timer, we need some kind of "context"
for timing related functions.

Simple example: xnpod_suspend_thread() expects a timeout as "xnticks",
i.e. either in nanoseconds or in ticks of the underlying periodic timer.
This depends on the global timer mode of the pod, and that's a no-go for
concurrent modes as sketched above. Rather, the thread should encode
which kind of timing mode to use, even better the threads timers.

We currently dispatch xntimer_start globally to the different timer
subsystems (if periodic mode is enabled). What about deriving the start
function from the timer itself in the future? If a timer was created as
aperiodic, things happen as usual in aperiodic mode, and the timeout are
interpreted as nanoseconds. If the timer is periodic, we interpret the
timeout in ticks and map them on a second-level timing subsystem
(probably a wheel) that itself is driven by a single periodic timer in
the first-level system (just like the host tick).

Am I heading in the right direction? Is it feasible? Any other ideas?

Jan


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

Re: [Xenomai-core] Towards periodic mode over aperiodic timers

[Philippe Gerum]

On Thu, 2006-08-17 at 15:27 +0200, Jan Kiszka wrote:
> Hi,
> 
> the conflict between skins preferring aperiodic timing vs. skin
> requiring periodic mode popped up once again on xenomai-help. One way
> out of this, likely THE way, is to map such tick-driven skins on a
> periodic timer over aperiodic mode (and drop periodic low-level support
> completely at the same time).
> 
> Let's start some discussion how this can be done, specifically as Gilles
> and I are already turning the xntimer subsystem upside down (almost). If
> we want co-existence of high-res timing of, say, the posix skin while
> the vxworks skin runs over a tick-timer, we need some kind of "context"
> for timing related functions.
> 
> Simple example: xnpod_suspend_thread() expects a timeout as "xnticks",
> i.e. either in nanoseconds or in ticks of the underlying periodic timer.
> This depends on the global timer mode of the pod, and that's a no-go for
> concurrent modes as sketched above. Rather, the thread should encode
> which kind of timing mode to use, even better the threads timers.
> 
> We currently dispatch xntimer_start globally to the different timer
> subsystems (if periodic mode is enabled). What about deriving the start
> function from the timer itself in the future? If a timer was created as
> aperiodic, things happen as usual in aperiodic mode, and the timeout are
> interpreted as nanoseconds. If the timer is periodic, we interpret the
> timeout in ticks and map them on a second-level timing subsystem
> (probably a wheel) that itself is driven by a single periodic timer in
> the first-level system (just like the host tick).
> 
> Am I heading in the right direction? Is it feasible? Any other ideas?

I like this idea; it's simple and elegant, having only a low impact on
the existing interfaces.

The two-level timer handling moving the BSD wheel on top of the
aperiodic shot is definitely a clean approach, which adds no overhead to
the existing periodic timer management. This would also allow to get rid
of the specific Adeos support for periodic hw management.

-- 
Philippe.

Re: [Xenomai-core] Towards periodic mode over aperiodic timers

[Jan Kiszka]

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

Philippe Gerum wrote:
> On Thu, 2006-08-17 at 15:27 +0200, Jan Kiszka wrote:
>> Hi,
>>
>> the conflict between skins preferring aperiodic timing vs. skin
>> requiring periodic mode popped up once again on xenomai-help. One way
>> out of this, likely THE way, is to map such tick-driven skins on a
>> periodic timer over aperiodic mode (and drop periodic low-level support
>> completely at the same time).
>>
>> Let's start some discussion how this can be done, specifically as Gilles
>> and I are already turning the xntimer subsystem upside down (almost). If
>> we want co-existence of high-res timing of, say, the posix skin while
>> the vxworks skin runs over a tick-timer, we need some kind of "context"
>> for timing related functions.
>>
>> Simple example: xnpod_suspend_thread() expects a timeout as "xnticks",
>> i.e. either in nanoseconds or in ticks of the underlying periodic timer.
>> This depends on the global timer mode of the pod, and that's a no-go for
>> concurrent modes as sketched above. Rather, the thread should encode
>> which kind of timing mode to use, even better the threads timers.
>>
>> We currently dispatch xntimer_start globally to the different timer
>> subsystems (if periodic mode is enabled). What about deriving the start
>> function from the timer itself in the future? If a timer was created as
>> aperiodic, things happen as usual in aperiodic mode, and the timeout are
>> interpreted as nanoseconds. If the timer is periodic, we interpret the
>> timeout in ticks and map them on a second-level timing subsystem
>> (probably a wheel) that itself is driven by a single periodic timer in
>> the first-level system (just like the host tick).
>>
>> Am I heading in the right direction? Is it feasible? Any other ideas?
> 
> I like this idea; it's simple and elegant, having only a low impact on
> the existing interfaces.
> 
> The two-level timer handling moving the BSD wheel on top of the
> aperiodic shot is definitely a clean approach, which adds no overhead to
> the existing periodic timer management. This would also allow to get rid
> of the specific Adeos support for periodic hw management.
> 

One could then even think about making the support switch for periodic
mode a per-skin option for those that support both modes.

That all sounds thrilling, but will certainly require some noticeable
refactoring. Maybe we can start with adding the required bits to the
existing aperiodic timer subsystem while keeping the periodic
infrastructure. Oh my dear, I'm already regretting having made that
suggestion... ;)

Jan


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

Re: [Xenomai-core] Towards periodic mode over aperiodic timers

[Philippe Gerum]

On Fri, 2006-08-18 at 14:14 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Thu, 2006-08-17 at 15:27 +0200, Jan Kiszka wrote:
> >> Hi,
> >>
> >> the conflict between skins preferring aperiodic timing vs. skin
> >> requiring periodic mode popped up once again on xenomai-help. One way
> >> out of this, likely THE way, is to map such tick-driven skins on a
> >> periodic timer over aperiodic mode (and drop periodic low-level support
> >> completely at the same time).
> >>
> >> Let's start some discussion how this can be done, specifically as Gilles
> >> and I are already turning the xntimer subsystem upside down (almost). If
> >> we want co-existence of high-res timing of, say, the posix skin while
> >> the vxworks skin runs over a tick-timer, we need some kind of "context"
> >> for timing related functions.
> >>
> >> Simple example: xnpod_suspend_thread() expects a timeout as "xnticks",
> >> i.e. either in nanoseconds or in ticks of the underlying periodic timer.
> >> This depends on the global timer mode of the pod, and that's a no-go for
> >> concurrent modes as sketched above. Rather, the thread should encode
> >> which kind of timing mode to use, even better the threads timers.
> >>
> >> We currently dispatch xntimer_start globally to the different timer
> >> subsystems (if periodic mode is enabled). What about deriving the start
> >> function from the timer itself in the future? If a timer was created as
> >> aperiodic, things happen as usual in aperiodic mode, and the timeout are
> >> interpreted as nanoseconds. If the timer is periodic, we interpret the
> >> timeout in ticks and map them on a second-level timing subsystem
> >> (probably a wheel) that itself is driven by a single periodic timer in
> >> the first-level system (just like the host tick).
> >>
> >> Am I heading in the right direction? Is it feasible? Any other ideas?
> > 
> > I like this idea; it's simple and elegant, having only a low impact on
> > the existing interfaces.
> > 
> > The two-level timer handling moving the BSD wheel on top of the
> > aperiodic shot is definitely a clean approach, which adds no overhead to
> > the existing periodic timer management. This would also allow to get rid
> > of the specific Adeos support for periodic hw management.
> > 
> 
> One could then even think about making the support switch for periodic
> mode a per-skin option for those that support both modes.
> 
> That all sounds thrilling, but will certainly require some noticeable
> refactoring. Maybe we can start with adding the required bits to the
> existing aperiodic timer subsystem while keeping the periodic
> infrastructure. Oh my dear, I'm already regretting having made that
> suggestion... ;)
> 

Before we start implementing anything, there is still another issue (at
least) to address: how do we deal with the wall clock time, basically
xnpod_get_time/set_time, and the xnarch-level counterparts, after we
move the logic from the central pod to a per-thread/per-timer view? E.g. what
should xnpod_get_time() return when called over an ISR context? 

-- 
Philippe.

Re: [Xenomai-core] Towards periodic mode over aperiodic timers

[Gilles Chanteperdrix]

Philippe Gerum wrote:
 > Before we start implementing anything, there is still another issue (at
 > least) to address: how do we deal with the wall clock time, basically
 > xnpod_get_time/set_time, and the xnarch-level counterparts, after we
 > move the logic from the central pod to a per-thread/per-timer view? E.g. what
 > should xnpod_get_time() return when called over an ISR context? 

If we add an xntimer_base_t context, the each skin would initialize its
context (or even contexts, if a skin has several time bases), and pass a
pointer to a base to xnpod_get_time.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] Towards periodic mode over aperiodic timers

[Philippe Gerum]

On Fri, 2006-08-18 at 16:41 +0200, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>  > Before we start implementing anything, there is still another issue (at
>  > least) to address: how do we deal with the wall clock time, basically
>  > xnpod_get_time/set_time, and the xnarch-level counterparts, after we
>  > move the logic from the central pod to a per-thread/per-timer view? E.g. what
>  > should xnpod_get_time() return when called over an ISR context? 
> 
> If we add an xntimer_base_t context, the each skin would initialize its
> context (or even contexts, if a skin has several time bases), and pass a
> pointer to a base to xnpod_get_time.

Looks good. This would also solve the issue of having different wall
clocks for concurrent skins, which is still something we can't have
right now.

-- 
Philippe.