EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: RE: name resolution performance
From: "Jeff Hill" <[email protected]>
To: "'Kay-Uwe Kasemir'" <[email protected]>, "'EPICS Core Talk'" <[email protected]>
Date: Thu, 7 Jul 2005 12:42:46 -0600
> ~60000 lookups (or is it connections?) 

That number includes also 60000 asynchronous round trips through the TCP
circuit to establish the channel in the server.

> 
> What's harder to measure/test/compare:
> When I start a new EDM screen, it connects quickly,
> which I guess is because of the 60000/sec.
> But when I reboot all ~40 SCL LLRF IOCs,
> the screen will often not reconnect for a minute.
> 

It should, by design, reconnect very quickly if it sees the LLRF IOC's
beacon anomaly.

Of course having to wait a minute when ~40 SCL LLRF IOCs reboot might be
related to rebooting delays (possibly boot server resource consumption
saturation delays) and have nothing to do with CA reconnect delays.
Furthermore, if an IOC's CPU was saturated because many clients are
connecting to it then CA will automatically back off on its search attempt
rate in order to reduce congestion. Finally, this may be a matter only of
academic curiosity given that a minute is easy overlooked when such major
reconfigurations of a control system occur?

> Is that because of SNS network misconfiguration?

Perhaps, I seem to recall that Earnest has the beacon address list set to
fan out to multiple subnets? You can run casw to see if the CA client
software is detecting a beacon anomaly.

Of course multicasting, and utilization of gateways for hierarchical load
management, would be an approach suitable for a multi-subnet system like the
SNS.

> Is the concept of detecting changes in beacon timing
> too tricky, and a straight directory lookup
> of where a PV is supposed to be would be quicker?
> 

It's not terribly hard to detect changes in beacon timing because (A)
beacons don't exist from an IOC when it's turned off or inaccessible, and
(B) the beacon is flashed using an exponential back off when the IOC
reboots.

The problem being solved with beacons isn't finding the server, but instead
fulfilling the following two requirements while minimizing network bandwidth
consumption.

1) Client notification when a newly accessible IOC joins the network
2) Periodically communicating a tangible indication of responsiveness to
clients with idle TCP circuits.

Recall that broadcasts and multicasts are actually less network bandwidth
intensive when you need to convey the same message to multiple clients.

Jeff



References:
Re: name resolution performance Kay-Uwe Kasemir

Navigate by Date:
Prev: Re: Record support and user-defined fields Andrew Johnson
Next: Re: Record support and user-defined fields Kay-Uwe Kasemir
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: name resolution performance Kay-Uwe Kasemir
Next: Re: Agenda for next week Benjamin Franksen
Index: 2002  2003  2004  <20052006  2007  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 ·