Hi Tom,
On 10/23/2013 04:14 AM, [email protected] wrote:
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.
You're not the first person to report this (the earlier one was
private), and actually the last commit that I made to the 3.14 branch
changed periodicTask() to fix this problem and add more information to
the error message. Base version 3.14.12.4 and later will make the
over-run penalty delay half the scan period, up to a maximum of 1
second, using this expression:
(ppsl->period >= 2) ? 1 : (ppsl->period / 2)
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...
The penalty delay is probably not really needed on Workstation OSs, but
on UP systems with priority scheduling it prevents the thread from
potentially using up all of the available CPU time. Making the penalty
equal to the sleep quantum may not be enough protection from that issue.
I have modified the patch on the Known Problems page to use the above
expression.
Thanks,
- Andrew
--
Advertising may be described as the science of arresting the human
intelligence long enough to get money from it. -- Stephen Leacock
- 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
- RE: time drift in camonitor timestamps tom.cobb
- Navigate by Date:
- Prev:
RE: time drift in camonitor timestamps tom.cobb
- Next:
Prosilica GX1050 - dual port GigE and areaDetector Piccoli, Luciano
- 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 tom.cobb
- 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
|