Experimental Physics and
Industrial Control System

Ø  Is there a reason we shouldn't slightly increase the queue size in base to avoid this? Even around 2500 for example should solve this issue.

 

Increasing to 2500 would solve it for your specific IOC, but if you then decide to load 20 ROI plugins rather than 5 that might not be enough.

 

I think 2000 was chosen to keep memory footprint low for RTEMS and vxWorks, while being large enough that overflows are rare in most IOCs.

 

A better solution is to add callbackSetQueueSize(5000) to ADCore/iocBoot/EXAMPLE_commonPlugins.cmd.  I will do that. 

 

That will work with any version of base, and could be modified by the site or specific IOC.

 

This is the number of records of each type in a standard simDetector IOC that loads commonPlugins.cmd.

 

epics> dbnr

Records  Aliases  Record Type

    18        0    sseq

   272        0    calcout

     9        0    seq

   138        0    stringout

   428        0    bo

    34        0    dfanout

   279        0    mbbi

    67        0    busy

   208        0    mbbo

   379        0    ao

    39        0    asyn

   496        0    waveform

     3        0    fanout

  2073        0    longin

   370        0    bi

   780        0    subArray

   162        0    calc

   732        0    longout

     4        0    scalcout

     2        1    sub

   587        1    ai

   519        0    stringin

     5        0    sscan

Total 7604 records, 2 aliases

 

The input records are the ai, bi, mbbi, longin, stringin and some of the waveform records.  Most of these have SCAN=I/O Intr and so do callbacks at iocInit.  This is nearly 3900 records, which is why 2000 is sometimes not a large enough queue.  It depends on the speed at which the records can process compared to the rate at which the asynPortDrivers do callbacks at iocInit.  A queue size of 5000 seems like it should be enough.

 

Mark