[Xenomai-core] autostart timer, rt_timer_start/stop

[Xenomai-core] autostart timer, rt_timer_start/stop

[Stefan Kisdaroczi]

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

Hi,

cant the timer be started by default ?

The current state (2.0.1) seems to lead to the following scenario:
1) Every app calls rt_timer_start()
2) If you call rt_timer_stop you can hurt other rt-apps, so dont
   call it
3) As some apps dont stop the timer, check in 1) if its already running

I think most apps do not care in which mode the timer is running if it is already,
and just go on, of course you can stop and restart the timer if its a wrong state,
but you do not know if you hurt others.

Now, as i read in the other thread that the periodic timer support isnt configured by default,
why not start the oneshot timer automatic ?

Like this, a 'normal' app doesnt need to fiddle with the timer and
an app that really cares can still call rt_timer_inquire,_stop,_start.

kisda


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

Re: [Xenomai-core] autostart timer, rt_timer_start/stop

[Jan Kiszka]

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

Stefan Kisdaroczi wrote:
> Hi,
> 
> cant the timer be started by default ?
> 
> The current state (2.0.1) seems to lead to the following scenario:
> 1) Every app calls rt_timer_start()
> 2) If you call rt_timer_stop you can hurt other rt-apps, so dont
>    call it
> 3) As some apps dont stop the timer, check in 1) if its already running
> 
> I think most apps do not care in which mode the timer is running if it is already,
> and just go on, of course you can stop and restart the timer if its a wrong state,
> but you do not know if you hurt others.
> 
> Now, as i read in the other thread that the periodic timer support isnt configured by default,
> why not start the oneshot timer automatic ?
> 
> Like this, a 'normal' app doesnt need to fiddle with the timer and
> an app that really cares can still call rt_timer_inquire,_stop,_start.
> 

Yea, that's good that someone else brings this topic up again! :) I've
been pointing on this several times, but as we did not come to a
conclusion how to handle the system timer in a consistent way across all
skins, no one (me included...) came up with a fix of this issue so far.

The thing is that most skins start the timer during module init via some
parameter (nowadays also as a kernel boot option for compiled-in skins).
As far as I remember, only the native and the RTAI compat skin do their
own dance - the latter one has to remain compatible, ok, but the former
one should be allowed to perform smarter.

Ok, to be more concrete: autostarting the one-shot time in the absence
of periodic mode is certainly worth considering. For the other cases and
as sysfs is no option on 2.4 kernels, what about adding a /proc-exported
control mechanism for the timer mode (and period) to either the HAL or
the nucleus? Additionally, we could provide some CONFIG_xyz to set the
default mode during compile time.

Ceterum censeo rt_timer_start/stop esse delendam. ;)

Jan

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

Re: [Xenomai-core] autostart timer, rt_timer_start/stop

[Philippe Gerum]

Jan Kiszka wrote:
> Stefan Kisdaroczi wrote:
> 
>>Hi,
>>
>>cant the timer be started by default ?
>>
>>The current state (2.0.1) seems to lead to the following scenario:
>>1) Every app calls rt_timer_start()
>>2) If you call rt_timer_stop you can hurt other rt-apps, so dont
>>   call it
>>3) As some apps dont stop the timer, check in 1) if its already running
>>
>>I think most apps do not care in which mode the timer is running if it is already,
>>and just go on, of course you can stop and restart the timer if its a wrong state,
>>but you do not know if you hurt others.
>>
>>Now, as i read in the other thread that the periodic timer support isnt configured by default,
>>why not start the oneshot timer automatic ?
>>
>>Like this, a 'normal' app doesnt need to fiddle with the timer and
>>an app that really cares can still call rt_timer_inquire,_stop,_start.
>>
> 
> 
> Yea, that's good that someone else brings this topic up again! :) I've
> been pointing on this several times, but as we did not come to a
> conclusion how to handle the system timer in a consistent way across all
> skins, no one (me included...) came up with a fix of this issue so far.
> 

Looks like pending, indeed:
https://gna.org/bugs/?func=detailitem&item_id=4551

> The thing is that most skins start the timer during module init via some
> parameter (nowadays also as a kernel boot option for compiled-in skins).
> As far as I remember, only the native and the RTAI compat skin do their
> own dance - the latter one has to remain compatible, ok, but the former
> one should be allowed to perform smarter.
> 
> Ok, to be more concrete: autostarting the one-shot time in the absence
> of periodic mode is certainly worth considering. For the other cases and
> as sysfs is no option on 2.4 kernels, what about adding a /proc-exported
> control mechanism for the timer mode (and period) to either the HAL or
> the nucleus?

Nucleus.

  Additionally, we could provide some CONFIG_xyz to set the
> default mode during compile time.
> 

Since we can't have more than a single timer setting at any time, a 
CONFIG switch in the General menu would be ok. In such a case, moving 
the currently arch-dep CONFIG_XENO_HW_PERIODIC_TIMER to the General 
config section would make sense too, so that we would have all timer 
options at the same place (periodic timing can always be emulated using 
some underlying oneshot hw timer, and all archs are expected to provide 
at least some form of oneshot timer anyway).

> Ceterum censeo rt_timer_start/stop esse delendam. ;)
> 

Perhaps not, otherwise we would have some trouble crafting tests and 
benchmarks for instance. But these are indeed relics from the Stone Age 
we'd better deprecate for normal use.

> Jan


-- 

Philippe.

Re: [Xenomai-core] autostart timer, rt_timer_start/stop

[Jan Kiszka]

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

Philippe Gerum wrote:
> Jan Kiszka wrote:
> 
>> Stefan Kisdaroczi wrote:
>>
>>> Hi,
>>>
>>> cant the timer be started by default ?
>>>
>>> The current state (2.0.1) seems to lead to the following scenario:
>>> 1) Every app calls rt_timer_start()
>>> 2) If you call rt_timer_stop you can hurt other rt-apps, so dont
>>>   call it
>>> 3) As some apps dont stop the timer, check in 1) if its already running
>>>
>>> I think most apps do not care in which mode the timer is running if
>>> it is already,
>>> and just go on, of course you can stop and restart the timer if its a
>>> wrong state,
>>> but you do not know if you hurt others.
>>>
>>> Now, as i read in the other thread that the periodic timer support
>>> isnt configured by default,
>>> why not start the oneshot timer automatic ?
>>>
>>> Like this, a 'normal' app doesnt need to fiddle with the timer and
>>> an app that really cares can still call rt_timer_inquire,_stop,_start.
>>>
>>
>>
>> Yea, that's good that someone else brings this topic up again! :) I've
>> been pointing on this several times, but as we did not come to a
>> conclusion how to handle the system timer in a consistent way across all
>> skins, no one (me included...) came up with a fix of this issue so far.
>>
> 
> Looks like pending, indeed:
> https://gna.org/bugs/?func=detailitem&item_id=4551
> 

Ha, totally forgot this one - I actually posted it. :)

>> The thing is that most skins start the timer during module init via some
>> parameter (nowadays also as a kernel boot option for compiled-in skins).
>> As far as I remember, only the native and the RTAI compat skin do their
>> own dance - the latter one has to remain compatible, ok, but the former
>> one should be allowed to perform smarter.
>>
>> Ok, to be more concrete: autostarting the one-shot time in the absence
>> of periodic mode is certainly worth considering. For the other cases and
>> as sysfs is no option on 2.4 kernels, what about adding a /proc-exported
>> control mechanism for the timer mode (and period) to either the HAL or
>> the nucleus?
> 
> 
> Nucleus.
> 
>  Additionally, we could provide some CONFIG_xyz to set the
> 
>> default mode during compile time.
>>
> 
> Since we can't have more than a single timer setting at any time, a
> CONFIG switch in the General menu would be ok. In such a case, moving
> the currently arch-dep CONFIG_XENO_HW_PERIODIC_TIMER to the General
> config section would make sense too, so that we would have all timer
> options at the same place (periodic timing can always be emulated using
> some underlying oneshot hw timer, and all archs are expected to provide
> at least some form of oneshot timer anyway).
> 
>> Ceterum censeo rt_timer_start/stop esse delendam. ;)
>>
> 
> Perhaps not, otherwise we would have some trouble crafting tests and
> benchmarks for instance. But these are indeed relics from the Stone Age
> we'd better deprecate for normal use.
> 

Let's assume we have extended /proc/xenomai/timer by accepting the timer
period as input (comparable to tick_hz module paramters of some skins),
we could simply tune it at benchmark startup by issuing "echo 0 >
/proc/xenomai/timer", either in the start script or from within the
application.

BTW, would the /proc/xenomai/timer interface make sense to you?

Jan

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