![]() |
![]() ![]()
Experimental Physics and
| ||||||||||||||
|
Hi Abdalla, For record processing triggered by incoming data (usually SCAN=I/O Intr), there are queues - one for each of the three EPICS Database priorities - that hold the processing requests. By default, these queues are pretty short. To handle bursts better, you can increase the queue sizes. This can be done from the startup script (see [1]) before running 'iocInit'. There is a watermark facility (available through the iocShell or devIocStats) that can show you how much of the queues is actually used. If your IOC is overloaded, i.e., continuously more records are added to the callback queue than the IOC is able to process, growing the queue size will obviously not help. In that situation, you can split the IOC, as you did. You can also allow multiple callback threads to process records in parallel (see [2]), making use of more cores of your CPU. *Careful:* If your driver is ASYN-based, the parallel threads solution will not work because of a design flaw or bug (still unclear) in ASYN. Splitting the IOC will work in any case. Cheers, ~Ralph [1] https://docs.epics-controls.org/en/latest/appdevguide/IOCInit.html#changing-ioccore-fixed-limits [2] Chapter "Parallel Callback Tasks" in the App Developers Guide https://epics.anl.gov/base/R3-16/2-docs/AppDevGuide.pdf
| ||||||||||||||
ANJ, 06 May 2025 |
![]() · Download · Search · IRMIS · Talk · Documents · Links · Licensing · |