Re: Question about two minor issues with IOCs

[Ralph Lange via Tech-talk <tech-talk@aps.anl.gov>]

In general,

all "I/O Intr" records may end up in the callback queue, and asynchronously processed records with PINI=YES will be in the scanOnce queue first, then (for the second phase processing) in the callback queue. Batched processing of asynchronous records (e.g. many records in one SCAN phase) may put the whole batch in the callback queue at once - depending on your Device Support. Callback queues are by priority, so spreading the record priorities will change the load. Using multiple parallel (concurrent) callback threads on multi-core IOCs gets the queues emptied faster. 

For some of ITER's conventional systems IOCs (connecting to large PLCs with >100k interfaced signals) we are using queue sizes well over 100k. Fine on Linux, where this is "just" memory.

Failing to find a formula that would come up with a good queue size for any specific IOC, we now tell users to just gradually increase the queue size until they don't get overflow messages anymore.

Cheers,
~Ralph

On Thu, 16 Jan 2020 at 21:25, Mark Rivers via Tech-talk <tech-talk@aps.anl.gov> wrote:

Ø  I think that this is in fact a better solution. That way when adding plugins this number can be adjusted if necessary.

 

I have added callbackSetQueueSize(5000) to EXAMPLE_commonPlugins.cmd and pushed to the master branch on Github.