Experimental Physics and Industrial Control System
|
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
<2009>
2010
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
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
ANJ, 02 Feb 2012 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|