[Xenomai] rtdm_timer_start latency?
Kendall.Auel at 3DSystems.Com
Tue Feb 13 20:36:34 CET 2018
I encountered a similar problem with a hardware clock implementation. Our implementation of "ns_to_ticks" for the xnclock struct had a very small truncation error. Immediately after booting the system, we didn't see a problem. In that case the absolute time was small, thus making the truncation error negligible. However, after the system had been up a day or two, relative timers had a very large initial delay (100s of ms). Eventually the startup delays were many seconds, if the clock had been running for days. For relative time durations, the truncation in the time conversion was also negligible, so after the initial delay there was no problem.
You might take a look at ...xenomai/clock.c, there are a number of #ifdef statements for choosing which math functions to use.
In our case, the truncation occurred with this code (in our custom driver for the hardware timer):
ticks = xnarch_ulldiv(ns, 1000000000/TIMER_HZ, &rem);
Note the TIMER_HZ value is just a little less than 40000. Thus the truncation error is in the range from 0.0000000 to 0.000025 of the original ns value. In our case it was about 0.000010. If we didn't have a random-looking clock frequency we would have never noticed the issue.
Anyway, to fix the problem, we changed it to:
return xnarch_llimd(ns, TIMER_HZ, 1000000000);
I hope this helps,
(PS - does anybody have a good MS-Outlook compatible tool for bottom-posting?)
> -----Original Message-----
> From: Xenomai [mailto:xenomai-bounces at xenomai.org] On Behalf Of
> Lowell Gilbert
> Sent: Tuesday, February 13, 2018 9:04 AM
> To: xenomai at xenomai.org
> Subject: Re: [Xenomai] rtdm_timer_start latency?
> Lowell Gilbert <kludge at be-well.ilk.org> writes:
> > Lowell Gilbert <kludge at be-well.ilk.org> writes:
> >> Philippe Gerum <rpm at xenomai.org> writes:
> >>> On 02/09/2018 11:02 AM, Philippe Gerum wrote:
> >>>> On 02/09/2018 12:45 AM, Lowell Gilbert wrote:
> >>>>> Am I correct in assuming that when calling rtdm_timer_start(), I
> >>>>> should not be getting multi-second latencies before the first call
> >>>>> to the timer routine? Just checking before I dig in too far.
> >>>> Of course not. I suspect an absolute expiry time is given with a
> >>>> relative mode spec.
> >>> More generally, an absolute expiry time which is not based on the
> >>> right clock specified by the mode argument.
> >>> i.e.
> >>> expiry = rtdm_clock_monotonic(), mode =
> RTDM_TIMERMODE_REALTIME =>
> >>> BAD expiry = rtdm_clock_realtime(), mode =
> >>> => BAD expiry = rtdm_clock_realtime() or _monotonic(), mode =
> >>> RTDM_TIMERMODE_RELATIVE => BAD
> >> Okay, that makes sense.
> >> I was using 0 for expiry, because I really just wanted the periodic
> >> wakeup. I don't remember why I didn't create a periodic task instead
> >> of using a timer.
> >> What clock do I want to use to get the timer started? Once it starts,
> >> it runs fine; but it often takes two or three seconds before the
> >> first call into the handler.
> >> To put it another way, I'm trying to figure out what am I doing wrong in:
> >> ret = rtdm_timer_start(&pstate.collect.timer, 1,
> >> pstate.collect.period,
> >> RTDM_TIMERMODE_RELATIVE);
> > I could just rewrite the code to use a periodic task, but I'd prefer
> > to understand what is actually wrong with my current code first, to be
> > sure that refactoring will really solve my problem.
> > Or I could have the timer run constantly, but that is just hacking
> > around the problem, not really solving it.
> I have a feature request that would require me to run the data collection
> constantly (or at least whenever there's a consumer ready to receive it), so
> that will ameliorate the problems for me. However, I'd prefer to understand
> what's happening, because as far as I understand at the moment, what I am
> doing *should* work.
> Also, as a matter of design, is there any reason to prefer a periodic task over
> a timer or vice versa? It can potentially cycle at fairly high rates (a period as
> low as 10 microseconds), although expected use cases will not.
> Be well.
> Xenomai mailing list
> Xenomai at xenomai.org
More information about the Xenomai