Re: time drift in camonitor timestamps

[Jack Smith <jacksmithvent2009@gmail.com>]

Wow, amazing! It seems Eric fixed the problem which has been known for
2.5 years.

A little bit off-topic question: when I look through periodicTask( )
which is the thread created by spawnPeriodic() for individual
corresponding scanning period, I don't see any kind of 'timer' to
trigger scanList(&ppsl->scan_list). So, my question is  how scanList(
) is periodically called in periodicTask( ) and where the 'timer'
thing is?

Thanks,

Jack


On Tue, Jan 8, 2013 at 12:46 PM, Eric Norum <wenorum@lbl.gov> wrote:
> This seems like it would be pretty easy to fix.
>
>
> --- dbScan.c 2011-12-12 12:14:45.000000000 -0800
> +++ dbScan.c.proposed 2013-01-08 09:43:23.000000000 -0800
> @@ -87,6 +87,7 @@
>      double              period;
>      volatile enum ctl   scanCtl;
>      epicsEventId        loopEvent;
> +    unsigned long       overrunCount;
>  } periodic_scan_list;
>
>  static int nPeriodic = 0;
> @@ -542,18 +543,23 @@
>  {
>      periodic_scan_list *ppsl = (periodic_scan_list *)arg;
>
> -    epicsTimeStamp start_time, end_time;
> +    epicsTimeStamp nextScan, now;
>      double delay;
>
>      taskwdInsert(0, NULL, NULL);
>      epicsEventSignal(startStopEvent);
>
> +    epicsTimeGetCurrent(&nextScan);
>      while (ppsl->scanCtl != ctlExit) {
> -        epicsTimeGetCurrent(&start_time);
>          if (ppsl->scanCtl == ctlRun) scanList(&ppsl->scan_list);
> -        epicsTimeGetCurrent(&end_time);
> -        delay = ppsl->period - epicsTimeDiffInSeconds(&end_time,
> &start_time);
> -        if (delay <= 0.0) delay = 0.1;
> +        nextScan += ppsl->period;
> +        epicsTimeGetCurrent(&now);
> +        delay = epicsTimeDiffInSeconds(&nextScan, &now);
> +        if (delay <= 0.0) {
> +            ppsl->overrunCount++;
> +            delay = 0.01;
> +            epicsTimeGetCurrent(&nextScan);
> +        }
>          epicsEventWaitWithTimeout(ppsl->loopEvent, delay);
>      }
>
>
>
> On Jan 8, 2013, at 8:51 AM, Ralph Lange <Ralph.Lange@gmx.de> wrote:
>
> To answer your original question...
>
> Yes, this problem is known and documented since ~2.5 years, but not fixed
> yet [1].
>
> Even though people have been running into this issue every now and then
> (there was even support added to devIOCstats [2] to measure the error),
> no-one's pain was bad enough to invest the time to track it down and fix it.
>
> For >99% of the applications, it just does not matter if the scan period has
> an error in the order of a few promille.
>
> ~Ralph
>
> [1] https://bugs.launchpad.net/epics-base/+bug/597054
> [2] http://www.slac.stanford.edu/grp/cd/soft/epics/site/devIocStats/
>
>
> --
> Eric Norum
> wenorum@lbl.gov
>