Re: [Xenomai-core] RTDM timeout value
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. 50 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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] RTDM timeout value
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. 50 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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM timeout value
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. 50 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 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM timeout value
On 8/29/07, Philippe Gerum [EMAIL PROTECTED] 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. 50 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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM timeout value
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. 50 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@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM timeout value
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. 50 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 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
