[EMAIL PROTECTED] wrote:
> > Klaas Gadeyne wrote:
> >> I've noticed that threads which, in my ignorant opinion, are supposed
> >> to be sleeping, get woken up much earlier than I expect them to be.
> >>
> >> Please find attached a modified version of the trivial-periodic.c
> >> application, which creates a RT_TASK that should sleep as long as
> >> possible (i.e. until unblocked by a signal handler). However, the
> >> task gets woken up much earlier (and many times) _before_ that time it
> >> seems.
> >>
> >> head /tmp/app.txt
> >> current_time = 1207928393295939429
> >> sleep until 18446744073709551615
> >> [TIMERLOOP] Total errors = 1, return code = -110
> >> current_time = 1207928393296000379
> >> sleep until 18446744073709551615
> >> [TIMERLOOP] Total errors = 2, return code = -110
> >> current_time = 1207928393296005409
> >> sleep until 18446744073709551615
> >> [TIMERLOOP] Total errors = 3, return code = -110
> >> current_time = 1207928393296009604
> >>
> >> What did I overlook here?
> >
> > Probably an overflow issue: (RTIME)~0 will be converted to TSCs, and if
> > your box runs at > 1GHZ, the result of this conversion will by something
> > < (RTIME)~0 due to the overflow. And this can result in an absolute
> > timeout date (in TSC units) before the current date -> ETIMEDOUT. Can
> > you confirm this?
>
> I have no linux box at hand, but I noticed that [*]
> xntimer_do_start_aperiodic() passes its xnticks_t interval argument (which
> is an unsigned long long) to xnarch_ns_to_tsc, and that one expects a
> (signed) long long.
>
> If I did not make any calculation errors (a very small chance...) in "my"
> case "interval" > LLONG_MAX so there's already an overflow there.
The problem is that we can not change xnarch_ns_to_tsc to use
xnarch_ullimd instead of xnarch_llimd: xnarch_ns_to_tsc may be used to
convert negative differences. Anyway, I do not think there is an
overflow in llimd, otherwise you would get a processor exception, not a
silent truncation (at least on x86). To solve this issue, we should
probably switch to saturation arithmetic, but it would probably have a
huge impact on performance (and on code also, since we would have to use
xnarch_saturated_add(foo, bar) instead of foo + bar).
--
Gilles.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
