Hi Andrew,
Sorry to resurrect an old thread, but I think I have an issue with the 0.1s penalty for over-runs of periodic tasks. This means that if the 0.1s scan task overruns, it will delay by 0.1s, which causes it to overrun the next time, and for every scan forever. I've noticed this behaviour when we had a misbehaving IOC running on a badly configured realtime linux system. All scan threads would overrun once, but the 0.1s then overran every time after that.
Reducing the delay to a bit less than the fastest scan period fixes this. I set it to epicsThreadSleepQuantum(), but that is probably a bit drastic...
Thanks,
Tom Cobb
> -----Original Message-----
> From: [email protected] [mailto:tech-talk-
> [email protected]] On Behalf Of Andrew Johnson
> Sent: 09 January 2013 19:46
> To: [email protected]
> Cc: Eric Norum
> Subject: Re: time drift in camonitor timestamps
>
> 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
- Replies:
- Re: time drift in camonitor timestamps Andrew Johnson
- References:
- time drift in camonitor timestamps ibadillo
- Re: time drift in camonitor timestamps Jack Smith
- Re: time drift in camonitor timestamps Eric Norum
- Re: time drift in camonitor timestamps Andrew Johnson
- Navigate by Date:
- Prev:
RE: Proper initialisation of Motor Record .RMP value Mark Rivers
- 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>
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: time drift in camonitor timestamps Andrew Johnson
- 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>
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|