g+
g+ Communities
Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <2013 Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <2013
<== Date ==> <== Thread ==>

Subject: Re: time drift in camonitor timestamps
From: Eric Norum <wenorum@lbl.gov>
To: Ralph Lange <Ralph.Lange@gmx.de>, Andrew Johnson <anj@aps.anl.gov>
Cc: EPICS Tech-Talk <tech-talk@aps.anl.gov>
Date: Tue, 8 Jan 2013 09:46:14 -0800
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


Replies:
Re: time drift in camonitor timestamps Jack Smith
References:
time drift in camonitor timestamps ibadillo
RE: time drift in camonitor timestamps Mark Rivers
Re: time drift in camonitor timestamps Michael Davidsaver
Re: time drift in camonitor timestamps inari badillo
Re: time drift in camonitor timestamps Ralph Lange

Navigate by Date:
Prev: Re: time drift in camonitor timestamps Ralph Lange
Next: Re: time drift in camonitor timestamps Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <2013
Navigate by Thread:
Prev: Re: time drift in camonitor timestamps Ralph Lange
Next: Re: time drift in camonitor timestamps Jack Smith
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <2013
ANJ, 09 Jan 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·