EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: CA client (on IOC) question
From: "Dalesio, Leo `Bob`" <[email protected]>
To: "Andrew Johnson" <[email protected]>, "Ralph Lange" <[email protected]>
Cc: "EPICS Core Talk" <[email protected]>
Date: Tue, 8 Aug 2006 08:45:23 -0700
The initial implementation used asynchronous conncerion management. I assume that it still does. I do not know what drives the rebroadcast though.
If you send me the code, I'll look it over.
Bob 

-----Original Message-----
From: Andrew Johnson [mailto:[email protected]] 
Sent: Tuesday, August 08, 2006 8:39 AM
To: Ralph Lange
Cc: EPICS Core Talk
Subject: Re: CA client (on IOC) question

Ralph Lange wrote:
> 
> looking at bad things happening and logs from our network switches it 
> seems that the CA client that runs on the IOC does a name resolve 
> request whenever any record with a link pointing into nirwana (aka an 
> unconnected link) is being processed.
> Example: on IOC1, there are 100 records (scanned at 10 Hz) pointing to 
> 100 other records sitting on IOC2. As soon as IOC2 is down, IOC1 
> broadcasts a name resolution request for those 100 channels 10 times a 
> second.
> 
> Is that true? Is that smart?

I believe that is the case, we've had similar issues here.  I suspect this stuff could be rewritten to be completely event driven, but I don't claim to fully understand how it works or why it behaves like this at the moment.  dbGetLinkValue() calls dbCaGetLink() which looks at the connection state of the link: since pca->isConnected should be false, link_action must be zero and there should be no further action by the dbCaTask().  However since we're seeing some effect there must be something else going on, which I don't have time to study right now; volunteers welcome...

As a workaround, you should be able to connect the SDIS links of those records to some local record scanned every 10 seconds that provides the connection state to that IOC and prevents them scanning if it's offline
- maybe use SDIS=connrec.STAT and DISV=14 (LINK_ALARM).

We really shouldn't force people to have to adopt these kind of measures though, so if anyone comes up with a fix for this I'd love to include it in a future version of Base.

> (trying to find out why a single IOC going halfway down drives _all_ 
> our IOCs into 95+ percent of cpu usage)

Ouch.

- Andrew
--
Not everything that can be counted counts, and not everything that counts can be counted.
   -- Albert Einstein


References:
Re: CA client (on IOC) question Andrew Johnson

Navigate by Date:
Prev: Re: CA client (on IOC) question Andrew Johnson
Next: RE: CA client (on IOC) question Jeff Hill
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: CA client (on IOC) question Andrew Johnson
Next: RE: CA client (on IOC) question Jeff Hill
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·