EPICS Controls 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  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Prioritizing Channel Access per Record?
From: Brian Bevins <[email protected]>
To: [email protected]
Date: Tue, 18 Mar 2014 15:50:32 -0400
On 03/18/14 13:00, Ralph Lange wrote:
On 18.03.2014 17:30, Brian Bevins wrote:
The waveforms are soft records that have their buffers filled by dedicated threads, which then post events to process the records.

I only see the slowdown when a client is connected to the waveforms. Even with the waveform records processing normally, the "fast" records update normally as long as no CA clients monitor the waveforms. I interpreted this to mean that the CA traffic was the bottleneck, but maybe I'm wrong.

Hmmm... another idea:

Please check that you have no database links that would pull "fast" and "slow" records into the same lock set.

During record processing, waveforms are put in the CA send queue by reference, while atomic data is put directly into the queue. When the low-priority CA send thread later-on copies the data out of the record into the network buffer, it has to lock the record. (It can just copy from the queue for atomic data, which does not require locking.) Possible effect: if your database has link connections that pull waveform records and "fast" records into the same lock set, the "fast" records might block while CA copies data from the waveforms.

Perfectly harmless looking things, like SDIS links pointing to the same "disable" record, may easily pull far too many records into the same lock set. Making this kind of links ".CA" often helps by breaking up the lock sets without affecting function.

On 03/18/14 13:14, Andrew Johnson wrote:
The IOC shell 'dblsr' command shows you the IOC's lock-sets.

'dblsr * 1' will print all the lock-sets and their members, while 'dblrs
* 2' shows you the links between the records as well. Unfortunately the
output is a bit noisy. You can use a specific record name instead of the
* to see just the lock-set containing that record.

A very good point. I checked all the lock sets and each of my "fast" records and each of my waveforms is in its own set.

--
Brian S. Bevins, PE
Computer Scientist / Mechanical Engineer
Thomas Jefferson National Accelerator Facility

     "The urge to save humanity is almost always only a false-face
      for the urge to rule it."
                                     -- H. L. Mencken


References:
Prioritizing Channel Access per Record? Brian Bevins
RE: Prioritizing Channel Access per Record? Mark Rivers
Re: Prioritizing Channel Access per Record? Brian Bevins
Re: Prioritizing Channel Access per Record? Ralph Lange

Navigate by Date:
Prev: css bundles issues Chen Xue
Next: Re: Prioritizing Channel Access per Record? Brian Bevins
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Prioritizing Channel Access per Record? Andrew Johnson
Next: NIKHEF hall probes Pierrick Hanlet
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 17 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·