--- 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);
}
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/