EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  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  <20172018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Callback queue overflow
From: Andrew Johnson <[email protected]>
To: Eric Norum <[email protected]>, EPICS mailing list <[email protected]>
Date: Tue, 16 May 2017 12:36:05 -0500
Hi Eric,

On 05/16/2017 12:15 PM, Eric Norum wrote:
> I have an EPICS R3.14.12 Linux IOC with about 24000 records, many of
> which are SCAN=“I/O Intr”.   I see occasional messages indicating
> callback request queue overflow:
> 
>     -- 0:st.screen -- time-stamp -- May/16/17  1:29:02 --
>     callbackRequest: cbLow ring buffer full
>     -- 0:st.screen -- time-stamp -- May/16/17  1:29:59 --
>     -- 0:st.screen -- time-stamp -- May/16/17  2:59:02 --
>     callbackRequest: cbLow ring buffer full
>     -- 0:st.screen -- time-stamp -- May/16/17  2:59:54 --
>     -- 0:st.screen -- time-stamp -- May/16/17  7:59:02 --
>     callbackRequest: cbLow ring buffer full
>     callbackRequest: cbLow ring buffer full
>     -- 0:st.screen -- time-stamp -- May/16/17  8:00:02 --
> 
> I’ve attempted to increase the queue size, but maybe not enough:
> 
>     ###############################################################################
>     # Override some sizes -- this IOC has *lots* of records
>     callbackSetQueueSize(10000)
>     dbPvdTableSize(8192)
> 
> Is there any downside to setting the callback queue size to something
> really large, says 50000 or more?  Is there something else I should try?

The callback subsystem uses ring buffers (one for each priority) so
increasing the size just reserves more RAM for them. The down-side of
making large numbers of records "I/O Intr" scanned is that it will take
more time for them all to get processed, which might delay some other
unrelated records on the same callback queue. You may be able to use
PRIO to solve that though.

Another solution might be to have one "I/O Intr" record forward to an
event record which posts a soft-event to trigger all the others on the
same interrupt source

HTH,

- Andrew

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon

References:
Callback queue overflow Eric Norum

Navigate by Date:
Prev: Callback queue overflow Eric Norum
Next: Archiver appliance showing DESC field on pv details page. Alireza Panna
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Callback queue overflow Eric Norum
Next: Archiver appliance showing DESC field on pv details page. Alireza Panna
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
ANJ, 21 Dec 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·