I do see the message that Andrew referred to when the IOC boots:
osdMonotonicInit: Measuring CPU time-base frequency ... 25000172 ticks/sec.
I just modified the scaler record to print the current value of the
first counter in the callback routine. I print with errlogPrintf(),
rather than printf(), so it does not slow down the operation very much.
My scaler has a 10 MHz input on scaler[0], so the ticks are 100 ns.
This is what I see if the RATE=59. The expected delta tick is
1/59.*1e7=169492. The average delta for the first 6 readings is 163981,
which is pretty close.
updateCounts: posting scaler values counts[0]=74
updateCounts: posting scaler values counts[0]=150723
updateCounts: posting scaler values counts[0]=317296
updateCounts: posting scaler values counts[0]=483968
updateCounts: posting scaler values counts[0]=651202
updateCounts: posting scaler values counts[0]=817458
updateCounts: posting scaler values counts[0]=983962
This is what I see if RATE=60
updateCounts: posting scaler values counts[0]=65
updateCounts: posting scaler values counts[0]=186497
updateCounts: posting scaler values counts[0]=188068
updateCounts: posting scaler values counts[0]=188639
updateCounts: posting scaler values counts[0]=189067
updateCounts: posting scaler values counts[0]=189495
updateCounts: posting scaler values counts[0]=189924
updateCounts: posting scaler values counts[0]=190351
So now the average delta from the last 7 readings is 642 ticks, which
means the callback is running every 64 microseconds, or 15.6 kHz.
This confirms that the problem is indeed that the callback is being
called far too often when RATE=60.
If the problem is that callbackRequestDelay is returning too soon when
RATE=60 then I don't understand why the bo record .HIGH field is not
showing the same problem.
--
You received this bug notification because you are a member of EPICS
Core Developers, which is subscribed to EPICS Base.
Matching subscriptions: epics-core-list-subscription
https://bugs.launchpad.net/bugs/1861612
Title:
callbackRequestDelay not waiting for 1/60 sec on vxWorks
Status in EPICS Base:
New
Bug description:
The problem is documented in this tech-talk thread:
https://epics.anl.gov/tech-talk/2020/msg00308.php
In 7.0.3.1, but not in 7.0.3, callbackRequestDelay(1/60) results in
100% CPU time, most of the time in cbHigh.
This happens on vxWorks 6.9.4.1 and was first seen with the scaler
record with multiple types of scaler hardware and device support.
To manage notifications about this bug go to:
https://bugs.launchpad.net/epics-base/+bug/1861612/+subscriptions
- References:
- [Bug 1861612] [NEW] callbackRequestDelay not waiting for 1/60 sec on vxWorks rivers via Core-talk
- Navigate by Date:
- Prev:
[Bug 1861612] Re: callbackRequestDelay not waiting for 1/60 sec on vxWorks rivers via Core-talk
- Next:
[Bug 1861612] Re: callbackRequestDelay not waiting for 1/60 sec on vxWorks Ralph Lange via Core-talk
- Index:
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:
[Bug 1861612] Re: callbackRequestDelay not waiting for 1/60 sec on vxWorks rivers via Core-talk
- Next:
[Bug 1861612] Re: callbackRequestDelay not waiting for 1/60 sec on vxWorks Ralph Lange via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024
|