Experimental Physics and
Industrial Control System

Michael Davidsaver <[email protected]> · Fri, 4 May 2018 11:26:21 -0700

On 05/04/2018 06:11 AM, Konrad, Martin wrote:
> Hi,
> I recently had to tweak the size of the cbLow and scanOnce queues on a
> bunch of IOCs hosting a large number of PVs. Due to a lack of
> diagnostics this turned out to be more tedious than I think it should
> be. I was able to simplify the process by implementing simple IOC shell
> functions that print queue usage and overflow information (see [1]). I'm
> wondering if this might be useful enough to others to include this in Base.
> 
> I'm actually still undecided _where_ this kind of diagnostics should go
> - into an IOC shell function or maybe into iocStats so it can be
> monitored continuously? Pushing this to iocStats would probably require
> a few changes to callback.[ch] to provide read access to some internal
> data structures.
> 
> Any thoughts?

Rather than hand tuning the queue size, my answer has been to look at bounding it,
or avoiding it all together.

Base 3.15.0.2 included API changes designed to make this possible.

* callbackRequest() changed to return an error if the queue is full.
* scanIoRequest() changed to return a bit mask showing the callback queues (priorities) into which work was added
* new scanIoSetComplete() sets a callback when I/O Intr work in a queue completes (after dbProcess())

A driver can call scanIoRequest() and know if any record scans were queued,
and if so, to get notifications so that it can wait for all scanning to complete.

This allows a driver to keep track of, and limit, how much of the callback queues it is using.

This is fairly complicated, so to simplify things Base 3.16.0.1 adds scanIoImmediate()
which simply lets driver thread(s) take the place of the shared callback threads.

> unsigned int scanIoImmediate(IOSCANPVT pios, int prio);

Given a I/O Intr scan list, and priority, it will directly scan any records on this list.

Both approaches are discussed (with examples) in:

http://mdavidsaver.github.io/epics-doc/epics-devsup.html#_rate_limiting_base_lt_3_16_0

My mrfioc2 driver uses the scanIoSetComplete() approach, and an even more tedious
one which works with 3.14, to prevent timing event driven scans from overflowing the
callback queues.

https://github.com/epics-modules/mrfioc2/blob/master/evrMrmApp/src/drvem.cpp#L1346

> [1]
> https://code.launchpad.net/~info-martin-konrad/epics-base/+git/epics-base/+ref/callbackQueueStatus

At a glance, I don't see any issues here.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System