Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: One CA server question
From: Ralph Lange <lange@bii.bessy.de>
To: saa@slac.stanford.edu
Cc: tech-talk@aps.anl.gov (EPICS Tech-Talk)
Date: Thu, 2 Sep 1999 15:40:50 +0200 (METDST)
Hi Stephanie,

> Question:  I've recently added diagnostics to my CA server to keep track
>            of the last 10 PVs broadcast to me that don't exist on my server.
>            I also keep a counter of the number of times non-existent PVs 
> 	   are requested and the time of the last request.  I see I'm being 
>            bombarded constantly with many PVs that belong on a totally 
>            different control system (BaBar - and a different subnet).  So 
>            there is a leak somewhere (probably the gateway).  Besides shutting
>            down each client until the problem goes away, are there other
>            less invasive techniques for finding "noisy" clients?  The server
>            runs on a VMS system with Multinet (there may be some Multinet
>            tool...).

This looks like a Channel Access inherent thing to me:

To properly handle CA connection breaks and reconnects, all CA servers
(including the CAS of the CA gateway) send out beacons signals. Not
regularily receiving a beacon signal from an IOC they are connected to
makes all CA clients mark all the connections to PVs on that IOC as
being down. When a beacon signal from a "new" IOC is received, all CA
clients repost all connection requests for all their PVs that are
down. (Because maybe the newly born CA server holds these variables.)
When these re-connection requests are broadcasted (i.e. if in the CA
client's environment EPICS_CA_AUTO_ADDR_LIST is != NO), all listening CA
servers receive these broadcasts, including the listening gateways.

You will notice these "storms" of connection requests whenever a new CA
server comes up, i.e. whenever any IOC reboots or any gateway process
comes up.

You may try to cut down these re-connection requests leaking through
your gateway by:
 o Setting up the PV list of the CA gateway in a way that allows access
   only for the PVs that your gateway should actually forward. Setting
   the list to "*" is certainly easier and faster (no need to sweep
   through the wildcard tables for each connection request), but it
   makes the gateway forward any connection request in the outside world
   as a broadcast into your net.
 o Setting up the PV list of your gateway to deny access to channels
   that are known not to be in your net (maybe you can think of a couple
   of wildcards that match all the BaBar channels). This has the same
   effect, but may be less effort then the "allow" settings depending on
   your naming convention.

Hope this helps,
Ralph


Replies:
RE: One CA server question Jeff Hill
References:
One CA server question and one CA server problem saa

Navigate by Date:
Prev: Re: One CA server problem Ralph Lange
Next: Re: One CA server problem saa
Index: 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: Re: One CA server problem Ralph Lange
Next: RE: One CA server question Jeff Hill
Index: 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·