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);
        if (rem)
        return ticks;

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-boun...@xenomai.org] On Behalf Of
> Lowell Gilbert
> Sent: Tuesday, February 13, 2018 9:04 AM
> To: xenomai@xenomai.org
> Subject: Re: [Xenomai] rtdm_timer_start latency?
> Lowell Gilbert <klu...@be-well.ilk.org> writes:
> > Lowell Gilbert <klu...@be-well.ilk.org> writes:
> >
> >> Philippe Gerum <r...@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 =
> >>> BAD expiry = rtdm_clock_realtime(), mode =
> >>> => BAD expiry = rtdm_clock_realtime() or _monotonic(), mode =
> >>
> >> 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@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

Xenomai mailing list

Reply via email to