EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: GW status
From: Ralph Lange <[email protected]>
To: "Ernest L. Williams Jr." <[email protected]>
Cc: "'Amedeo Perazzo'" <[email protected]>, Stephen Lewis <[email protected]>, "'Core-Talk'" <[email protected]>, "'Dirk Zimoch'" <[email protected]>
Date: Wed, 05 Aug 2009 12:06:34 -0400
Ernest L. Williams Jr. wrote:
Ralph Lange wrote:
Caching/no-caching:
Among the GW's objectives are keeping load off the IOCs and acting transparently. With certain aspects of Channel Access, e.g. answering get requests, forwarding IOC-side beacons to the clients, and forwarding client side name-resolution-requests to the IOCs, these two objectives are contrary. If the GW acts 100% transparent, it does not offload the IOCs (in some cases, it would even put more load onto the IOCs). If the GW tries to shield the IOCs, it will not be able to act completely transparent. While the original approach was trying to implement a reasonable compromise, the direction that Dirk is pursuing is certainly the right one: when the level of compromise is made configurable for these aspects, the user can select the appropriate behavior for each GW instance.
Ralph do you agree that with respect to TCP-circuit load the IOC does get shielded? So, yes the IOCs will get hit with search requests (UDP, BCAST) but this is as you say a trade-off. Also, statistically most connections to PVs are monitored as opposed to cagets.

Hi Ernest,
yes, the TCP circuit load is reduced, as there's only one circuit between the GW and the IOC. Note, though, that this usually only reduces memory consumption. For the CPU load, update rate (number of subscriptions and data rate) and search requests are more important.

Through a GW, only one TCP circuit is used, and the number of subscriptions for a PV will be limited to three (worst case: one subscription each for VALUE, ARCHIVE, and ALARM events). That's the result of a CA design flaw: when a client (in this case: the GW) sets up a subscription with multiple bits in the event type mask set, an incoming data update will not have the information which event type it is connected with. So, a GW with value, alarm and archive clients has to subscribe for value, alarm, and archive events separately to be able to send the right value updates to the right customers. So, in the rare worst case (one client asking through a GW for value, archive, and alarm) the number of subscriptions on the IOC will triple compared to a non-GW direct connection. Even the update rate and network load triple in the case of every PV change causing value, archive, and alarm events.

Still, you are right, in most real-world cases (with most connections being subscriptions), the GW will reduce the TCP circuit and the update rate load on the IOCs.

Ralph


Replies:
Re: GW status Dirk Zimoch
References:
RE: GW status Jeff Hill
Re: GW status Stephen Lewis
Re: GW status Ralph Lange
Re: GW status Ernest L. Williams Jr.

Navigate by Date:
Prev: Re: GW status Ernest L. Williams Jr.
Next: Re: GW status Dirk Zimoch
Index: 2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: GW status Ernest L. Williams Jr.
Next: Re: GW status Dirk Zimoch
Index: 2002  2003  2004  2005  2006  2007  2008  <20092010  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 ·