Re: time drift in camonitor timestamps

[Andrew Johnson <anj@aps.anl.gov>]

Hi Eric,

FYI Jack wasn't the reporter.

Your fixed version works fine for me.  I'm adding some code to print warnings 
about continuous overruns (at increasing periods, up to hourly) before I 
commit it.

I'm also inclined to keep the original delay = 0.1 penalty for an over-run 
instead of dropping it to 0.02 seconds, but I will consider arguments against 
that if there are objections.

- Andrew

On 2013-01-09 Eric Norum wrote:
> Sorry.
> Previous message had wrong periodicTask code.  Here's what I meant to send.
> 
> Jack, can you try this and see if it fixes the problem that you were
>  seeing/
> 
> 
> static void periodicTask(void *arg)
> {
>     periodic_scan_list *ppsl = (periodic_scan_list *)arg;
> 
>     epicsTimeStamp nextScan, now;
>     double delay;
> 
>     taskwdInsert(0, NULL, NULL);
>     epicsEventSignal(startStopEvent);
> 
>     epicsTimeGetCurrent(&nextScan);
>     while (ppsl->scanCtl != ctlExit) {
>         if (ppsl->scanCtl == ctlRun) scanList(&ppsl->scan_list);
>         epicsTimeAddSeconds(&nextScan, ppsl->period);
>         epicsTimeGetCurrent(&now);
>         delay = epicsTimeDiffInSeconds(&nextScan, &now);
>         if (delay <= 0.0) {
>             ppsl->overrunCount++;
>             delay = 0.02;
>             epicsTimeGetCurrent(&nextScan);
>         }
>         epicsEventWaitWithTimeout(ppsl->loopEvent, delay);
>     }
> 
>     taskwdRemove(0);
>     epicsEventSignal(startStopEvent);
> }

-- 
There is no such thing as a free lunch.  When invited for lunch,
it is best to check if you are there to eat, or to be eaten.
-- Clive Robinson