RE: No monitor refresh

["Mark Rivers" <rivers@cars.uchicago.edu>]

Hinko,
 
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?
 
Mark
 

________________________________

From: tech-talk-bounces@aps.anl.gov on behalf of Hinko Kocevar
Sent: Fri 5/14/2010 3:17 AM
To: tech-talk@aps.anl.gov
Subject: Re: No monitor refresh



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: hinko.kocevar@i-tech.si

http://www.i-tech.si <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.