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 <[email protected]> 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 <[email protected]> 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
> [email protected]
>
- Replies:
- Re: time drift in camonitor timestamps Eric Norum
- Re: time drift in camonitor timestamps Eric Norum
- 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
- Re: time drift in camonitor timestamps Eric Norum
- Navigate by Date:
- Prev:
Re: What's calling get_array_info? Tim Mooney
- Next:
Re: time drift in camonitor timestamps Eric Norum
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
<2013>
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: time drift in camonitor timestamps Eric Norum
- Next:
Re: time drift in camonitor timestamps Eric Norum
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
<2013>
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|