[Xenomai-core] RTDM timeout value

[Xenomai-core] RTDM timeout value

[Markus Osterried (BA/EDD)]

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

Hi,

it seems that in the RTDM API, all the timeout functions which use
nanosecs_rel_t have a strange behaviour.
The timeout in nanoseconds is converted to ticks and the number of ticks
is rounded down. So when we want to wait e.g. 500000 nanoseconds and the
timertick is 1 ms, xnpod_ns2ticks() rounds down to 0. But 0 is the
special value RTDM_TIMEOUT_INFINITE, so we wait forever. I use Xenomai
2.3.1, but I think it's basically the same in trunk.
Wouldn't it be better to round up the ticks instead of round it down?


Thanks
Markus


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

Re: [Xenomai-core] RTDM timeout value

[Jan Kiszka]

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

Markus Osterried (BA/EDD) wrote:
> Hi,
> 
> it seems that in the RTDM API, all the timeout functions which use
> nanosecs_rel_t have a strange behaviour.
> The timeout in nanoseconds is converted to ticks and the number of ticks
> is rounded down. So when we want to wait e.g. 500000 nanoseconds and the
> timertick is 1 ms, xnpod_ns2ticks() rounds down to 0. But 0 is the
> special value RTDM_TIMEOUT_INFINITE, so we wait forever. I use Xenomai
> 2.3.1, but I think it's basically the same in trunk.

It should even impact other skins as well when in tick-based timing
mode. I would bet more users of xnpod_ns2ticks() may have overseen this
rounding issue - like RTDM did.

> Wouldn't it be better to round up the ticks instead of round it down?

Hmm, probably. Mind to work out a patch for xnpod_ticks2ns()?

What do others think about this issue? Can/should we change the rounding
behaviour at nucleus level?

Thanks for reporting,
Jan


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

Re: [Xenomai-core] RTDM timeout value

[Philippe Gerum]

On Wed, 2007-08-29 at 16:32 +0200, Jan Kiszka wrote:
> Markus Osterried (BA/EDD) wrote:
> > Hi,
> > 
> > it seems that in the RTDM API, all the timeout functions which use
> > nanosecs_rel_t have a strange behaviour.
> > The timeout in nanoseconds is converted to ticks and the number of ticks
> > is rounded down. So when we want to wait e.g. 500000 nanoseconds and the
> > timertick is 1 ms, xnpod_ns2ticks() rounds down to 0. But 0 is the
> > special value RTDM_TIMEOUT_INFINITE, so we wait forever. I use Xenomai
> > 2.3.1, but I think it's basically the same in trunk.
> 
> It should even impact other skins as well when in tick-based timing
> mode. I would bet more users of xnpod_ns2ticks() may have overseen this
> rounding issue - like RTDM did.
> 

Other skins may only mean POSIX and native, since the other ones only
deal with ticks.

> > Wouldn't it be better to round up the ticks instead of round it down?
> 
> Hmm, probably. Mind to work out a patch for xnpod_ticks2ns()?
> 
> What do others think about this issue? Can/should we change the rounding
> behaviour at nucleus level?
> 

Clearly not. You don't change the core rounding policy for fixing
shortcomings in the higher levels, especially to fix invalid application
requests. I do want to be able to round down at nucleus level, which I
would not be able to do anymore with a rounding up policy at core level.
This change belongs to the skin which wants this behaviour.

> Thanks for reporting,
> Jan
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
-- 
Philippe.

Re: [Xenomai-core] RTDM timeout value

[Gilles Chanteperdrix]

On 8/29/07, Philippe Gerum <rpm@xenomai.org> wrote:
> On Wed, 2007-08-29 at 16:32 +0200, Jan Kiszka wrote:
> > Markus Osterried (BA/EDD) wrote:
> > > Hi,
> > >
> > > it seems that in the RTDM API, all the timeout functions which use
> > > nanosecs_rel_t have a strange behaviour.
> > > The timeout in nanoseconds is converted to ticks and the number of ticks
> > > is rounded down. So when we want to wait e.g. 500000 nanoseconds and the
> > > timertick is 1 ms, xnpod_ns2ticks() rounds down to 0. But 0 is the
> > > special value RTDM_TIMEOUT_INFINITE, so we wait forever. I use Xenomai
> > > 2.3.1, but I think it's basically the same in trunk.
> >
> > It should even impact other skins as well when in tick-based timing
> > mode. I would bet more users of xnpod_ns2ticks() may have overseen this
> > rounding issue - like RTDM did.
> >
>
> Other skins may only mean POSIX and native, since the other ones only
> deal with ticks.

AFAICT, the posix skin deals with this, most timeouts use
ts_2ticks_ceil(timeout)+1
which round the timeout (expressed as a struct timespec) to the next
tick, and add an additional tick to be sure to sleep at least the
specified duration, as required by the posix spec.

Of course, there may be places in the posix skin where I forgot about
this issue.
-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-core] RTDM timeout value

[Jan Kiszka]

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

Philippe Gerum wrote:
> On Wed, 2007-08-29 at 16:32 +0200, Jan Kiszka wrote:
>> Markus Osterried (BA/EDD) wrote:
>>> Hi,
>>>
>>> it seems that in the RTDM API, all the timeout functions which use
>>> nanosecs_rel_t have a strange behaviour.
>>> The timeout in nanoseconds is converted to ticks and the number of ticks
>>> is rounded down. So when we want to wait e.g. 500000 nanoseconds and the
>>> timertick is 1 ms, xnpod_ns2ticks() rounds down to 0. But 0 is the
>>> special value RTDM_TIMEOUT_INFINITE, so we wait forever. I use Xenomai
>>> 2.3.1, but I think it's basically the same in trunk.
>> It should even impact other skins as well when in tick-based timing
>> mode. I would bet more users of xnpod_ns2ticks() may have overseen this
>> rounding issue - like RTDM did.
>>
> 
> Other skins may only mean POSIX and native, since the other ones only
> deal with ticks.

Ah, yeah, of course.

POSIX is safe because it does well-defined rounding on its own. Native
itself has no problem, just the user may get informed about the rounding
behaviour of rt_timer_ns2ticks. Otherwise, things like rt_sem_p(sem,
rt_timer_ns2ticks(some_nanos)) may unexpectedly behave like RTDM does now.

> 
>>> Wouldn't it be better to round up the ticks instead of round it down?
>> Hmm, probably. Mind to work out a patch for xnpod_ticks2ns()?
>>
>> What do others think about this issue? Can/should we change the rounding
>> behaviour at nucleus level?
>>
> 
> Clearly not. You don't change the core rounding policy for fixing
> shortcomings in the higher levels, especially to fix invalid application
> requests. I do want to be able to round down at nucleus level, which I
> would not be able to do anymore with a rounding up policy at core level.
> This change belongs to the skin which wants this behaviour.

Agreed, we primarily need to fix RTDM here.

But what about introducing generic xnpod/xntbase_ns2ticks_floor/ceil()
for this? Would avoid more re-inventions of this common service.

Jan


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

Re: [Xenomai-core] RTDM timeout value

[Philippe Gerum]

On Wed, 2007-08-29 at 17:28 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Wed, 2007-08-29 at 16:32 +0200, Jan Kiszka wrote:
> >> Markus Osterried (BA/EDD) wrote:
> >>> Hi,
> >>>
> >>> it seems that in the RTDM API, all the timeout functions which use
> >>> nanosecs_rel_t have a strange behaviour.
> >>> The timeout in nanoseconds is converted to ticks and the number of ticks
> >>> is rounded down. So when we want to wait e.g. 500000 nanoseconds and the
> >>> timertick is 1 ms, xnpod_ns2ticks() rounds down to 0. But 0 is the
> >>> special value RTDM_TIMEOUT_INFINITE, so we wait forever. I use Xenomai
> >>> 2.3.1, but I think it's basically the same in trunk.
> >> It should even impact other skins as well when in tick-based timing
> >> mode. I would bet more users of xnpod_ns2ticks() may have overseen this
> >> rounding issue - like RTDM did.
> >>
> > 
> > Other skins may only mean POSIX and native, since the other ones only
> > deal with ticks.
> 
> Ah, yeah, of course.
> 
> POSIX is safe because it does well-defined rounding on its own. Native
> itself has no problem, just the user may get informed about the rounding
> behaviour of rt_timer_ns2ticks. Otherwise, things like rt_sem_p(sem,
> rt_timer_ns2ticks(some_nanos)) may unexpectedly behave like RTDM does now.
> 
> > 
> >>> Wouldn't it be better to round up the ticks instead of round it down?
> >> Hmm, probably. Mind to work out a patch for xnpod_ticks2ns()?
> >>
> >> What do others think about this issue? Can/should we change the rounding
> >> behaviour at nucleus level?
> >>
> > 
> > Clearly not. You don't change the core rounding policy for fixing
> > shortcomings in the higher levels, especially to fix invalid application
> > requests. I do want to be able to round down at nucleus level, which I
> > would not be able to do anymore with a rounding up policy at core level.
> > This change belongs to the skin which wants this behaviour.
> 
> Agreed, we primarily need to fix RTDM here.
> 
> But what about introducing generic xnpod/xntbase_ns2ticks_floor/ceil()
> for this? Would avoid more re-inventions of this common service.
> 

Agreed.

> Jan
> 
-- 
Philippe.