I really don't think you need to worry about the size of the
ring buffer. 10 values is probably fine. The purpose of the ring
buffer is to prevent losing callback values that come very close together in
time. For example, consider a binary input device that is I/O Intr
scanned on both rising and falling transitions. If a short pulse, say 50
microseconds, occurs, we want to EPICS to process the record on both the rising
and falling edges. The ring buffer allows that, because although the
record won't process within 50 microseconds, both values will be in the ring
buffer and the record will process twice. On the other hand if the pulses
come too frequently then no size ring buffer will help if EPICS cannot process
the record fast enough on average.
It sounds like your problem may be that some of
your callbacks are very CPU intensive. I run devices like the Acromag
IP330 16 channel ADC at more than 2,000 callbacks per second and it uses only
small fraction of the CPU. But those don't process the ai records at that
rate, it uses the asynInt32Average device support to average the readings between
periodic processing.
Are you saying that if you slow down some of your devices
then all of the callbacks do run correctly? What is the total number of
callbacks per second in your system?
Hi Mark,
On 05/13/10 12:16, Hinko Kocevar wrote:
>> devEpics
>>
>>
>> Undid the change that was done in R4-9 with direct calls to dbScanLock
and process in the interrupt callback functions. This could lead to deadlocks
in some circumstances. The original reason for changing from scanIoRequest to
(dbScanLock, process) was because callback values would be lost if the
callbacks came so close together in time that the single callback value stored
in device support was overwritten before scanIoRequest could process the
record. This problem has been fixed by adding a FIFO (ring buffer) to the
device support for the scalar interfaces asynInt32, asynUInt32Digital, and
asynFloat64. The ring buffer is only created when the record is put into I/O
Intr scan, so the storage is not allocated for records that are not I/O Intr
scanned. The ring buffer default size is 10 values, but this can be changed on
a per-record basis using the dbInfo string "FIFO" with a value such
as "100".
>>
I've upgraded the Asyn to 4-10 and I'm performing some tests.
How and where should I set the "FIFO" parameter? In each PV record?
I have several ports started in my IOC and some of them do periodic data
processing on external trigger signal - I/O Intr scanning. It looks like
some more intensive callbacks get all the attention and the slow (low
priority?) so not get serviced at all. Would this ring buffer size be
the solution ?
Is there a global 'ring buffer' for I/O Intr callbacks I need to worry
about - resize that is? My I/O Intr spawned callback rate is more than
15 per second, in different IOC ports/PVs. Looking at the debug output I
see that some callbacks do not get serviced. Only by disabling the port
initialization and processing relaxes the IOC and I/O Intr scanned
callback are processed in timely fashion.
Best regards,
Hinko
--
Hinko Kocevar
Technical support software engineer
Instrumentation Technologies
Velika pot 22, SI-5250 Solkan - Slovenia
T:+386 5 3352600, F:+386 5 3352601
mailto: [email protected]
http://www.i-tech.si - When your users
demand stability
The information transmitted is intended solely for the addressee and may
contain confidential and/or privileged information. Any review, retention,
disclosure or other use by persons other than the intended recipient is
prohibited. If you received this in error, please notify the sender and
delete all copies.