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  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: record ring buffer flushing
From: Hinko Kocevar <hinko.kocevar@i-tech.si>
To: Mark Rivers <rivers@cars.uchicago.edu>
Cc: EPICS tech-talk <tech-talk@aps.anl.gov>
Date: Fri, 27 May 2011 08:42:53 +0200
Dear Mark,

On 05/26/2011 08:02 PM, Mark Rivers wrote:
Hi Hinko,

You don't say so explicitly, I assume that you are using the standard
asyn device support, and that the ring buffer you are referring to is
the one in that device support?

Yes, and yes. It is SoftIOC running on Linux system, on ARM hardware. I'm not creating any ring buffers myself.


Even if we manage to 'disable' the processing inside the device driver

(in terms that no new data is written to record buffers, I/O intr
SCANing still active), it takes quite some time to process all the
pending requests already in the ring buffers for the corresponding
record.

How many records are involved?  By default each record only has 10
elements in its ring buffer, so each record would process at most 10
times before the ring buffer was empty.  This should be quite fast,
unless you have very many records in this state.

We are capturing array of data with bi record on I/O intr in a local EPICS buffer. BI record has FLNK to a waveform record that holds the actual data for PV - 8 PV are FLNKed in a sequence. Size of the buffer is 30000 integers.


There is no way to tell it to flush the buffer.

Thanks for clarifying this.


However, you can decrease the size of the ring buffer, down to a single
element if you want.  The ring buffer default size is 10 values, but
this can be changed on a per-record basis by setting the dbInfo string
"FIFO" to a different value.  In your case you could set the value to
"1".  The disadvantage of this is that if there are several callbacks in
rapid succession the record will only process on the last value, it will
not process with the other values.  This may be OK in your case.


Right, this might be just what we are looking for.

Our data is arriving quite fast, at 10Hz and the goal is to process the raw data internally in the EPICS and provide the output on some EPICS PVs. Processing of the data has significant impact on the CPU usage. Several other PVs (some single value, some array) need to updated on at each 100 ms interval. There is no use for data that is not delivered to user (via PV), hence we can discard it.

Along with this FIFO modification part, we might reconsider to implement some parts of our IOC in different way to avoid this congestion stuff all together.

Thank you!

Hinko

Mark




-----Original Message-----
From: tech-talk-bounces@aps.anl.gov
[mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Hinko Kocevar
Sent: Thursday, May 26, 2011 4:06 AM
To: EPICS tech-talk
Subject: record ring buffer flushing

Hi all,

We are running EPICS 3.14.10 on ARM based system. Our device driver is
using asyn driver.

There are several records that are processed on I/O intr SCAN. Sometimes

the I/O rate is quite high and the system load (CPU) goes over the top,
with high (>  3.0) loadavg. When this happens IOC is sluggish to respond
to any CA requests.

Even if we manage to 'disable' the processing inside the device driver
(in terms that no new data is written to record buffers, I/O intr
SCANing still active), it takes quite some time to process all the
pending requests already in the ring buffers for the corresponding
record.

Only then can we successfully use the CA to set/get any other PV on the
IOC, and not worry about the delayed response and/or timeouts.

Is there a way to tell IOC or a PV record to forget the pending
events/requests in its ring buffer (eg. some kind of flush)?

This way we could be sure that the IOC will be responding in timely
fashion, when we try to access some PV, and avoid waiting for the ring
buffer to empty by itself..

Has anyone dealt with similar situation?

Any comments and suggestions are welcomed!


Thank you,
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:
record ring buffer flushing Hinko Kocevar
RE: record ring buffer flushing Mark Rivers

Navigate by Date:
Prev: epicsTypes.h/inttypes.h question Till Straumann
Next: HV PSU suggestions tom.cobb
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: RE: record ring buffer flushing Mark Rivers
Next: epicsTypes.h/inttypes.h question Till Straumann
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·