Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: RE: No monitor refresh
From: "Mark Rivers" <rivers@cars.uchicago.edu>
To: "Hinko Kocevar" <hinko.kocevar@i-tech.si>, <tech-talk@aps.anl.gov>
Date: Fri, 14 May 2010 08:31:51 -0500
Title: Re: No monitor refresh

Hi Hinko,

 

If I understand correctly, your hypothesis is that the callbacks from the asyn driver to device support are happening, but that the record is not processing, perhaps because the EPICS callback task running scanIoRequest is not getting the CPU time it needs.

 

With asyn 4-10 there is a simple way to test this.  If that hypothesis is true then the ring buffer will be overflowing, because more than 10 callbacks happened without processing the record and removing values from the ring buffer.  If you force the record to process (use “dbtr myRecord” or “dbpf myRecord.PROC,”1” at the IOC shell) then you should see an error message about ring buffer overflow when the record processes.  If you do not see that error message then the hypothesis is wrong.

 

Mark

 

 


From: Mark Rivers
Sent: Friday, May 14, 2010 6:11 AM
To: Hinko Kocevar; tech-talk@aps.anl.gov
Subject: RE: No monitor refresh

 

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 - 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.


References:
Re: No monitor refresh Ralph Lange
Re: No monitor refresh Hinko Kocevar
RE: No monitor refresh Mark Rivers
Re: No monitor refresh Hinko Kocevar
RE: No monitor refresh Mark Rivers
Re: No monitor refresh Hinko Kocevar
Re: No monitor refresh Hinko Kocevar
RE: No monitor refresh Mark Rivers

Navigate by Date:
Prev: RE: No monitor refresh Mark Rivers
Next: RE: cygwin 1.7 compatibility Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: RE: No monitor refresh Mark Rivers
Next: RE: No monitor refresh Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·