Re: Callback queue overflow

[Andrew Johnson <anj@aps.anl.gov>]

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