> ~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
<2005>
2006
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
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|