EPICS Home EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

Format page
for printing


Search Tech-talk
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  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 
<== Date ==> <== Thread ==>
Subject: Re: Scan overflow issue
From: Ralph Lange via Tech-talk <tech-talk at aps.anl.gov>
To: EPICS Tech Talk <tech-talk at aps.anl.gov>
Date: Thu, 11 Aug 2022 15:54:08 +0200
On Thu, 11 Aug 2022 at 15:39, Zhang, Tong via Tech-talk <tech-talk at aps.anl.gov> wrote:

One of my IOC hosts ~20k records, when restarting it, sometimes it may throw "scanOnce: Ring buffer overflow" messages, which leads to some incorrect statistical calculations.

I guess this might come from:

  1. autosave, which will trig a bunch of crowded restoring, is that possible to slow down the process?
  2. It's too many records in one IOC, if so, what would you recommend? Dose splitting it into multiple ones help?
Please correct me if my understanding is wrong, and I appreciate any sharing on resolving this issue.

My guess: as all records that have PINI=YES are put in the internal queue for records that need to be processed once when the IOC boots, the default queue size of 1000 is too small for your IOC.
Use the command scanOnceSetQueueSize from your startup script (needs to be done before calling iocInit) to set the queue size to a larger value. (See "SetQueueSize" in the AppDevGuide.)
Recent versions of EPICS also have a high water mark mechanism for the internal queues. Looking at those values (from the iocShell or via iocStats) can give you an idea of how large the queues need to be.

Splitting the IOC would also help, obviously. But 20k is probably fine. We have been running IOCs with >100k records without issues. (But the queue sizes are certainly increased accordingly.)
The number is only one of the parameters... what kind of records, how much driver code is executing, how much IO is being done, how many calculations... the load depends on the combination.

Cheers,
~Ralph

Replies:
RE: Scan overflow issue Zhang, Tong via Tech-talk
References:
Scan overflow issue Zhang, Tong via Tech-talk
Navigate by Date:
Prev: Scan overflow issue Zhang, Tong via Tech-talk
Next: Re: pypva, PvObject and NTTable Veseli, Sinisa via Tech-talk
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: Scan overflow issue Zhang, Tong via Tech-talk
Next: RE: Scan overflow issue Zhang, Tong via Tech-talk
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 
ANJ, 14 Sep 2022 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·