Experimental Physics and
Industrial Control System

Dirk Zimoch <[email protected]> · Thu, 06 Aug 2009 09:29:35 +0200

Hi all,

The search broadcast load is reduced in any case simply because the gateway only

has to connect when the first client starts up. Then even when the client

terminates, the connection is held open for 2 hours. So no client started within

the next two hours will generate a new search request. The CPU load should also

be reduced because the IOC has to update only one client.

I think the gateway open a maximum of two subscriptions to a channel,

value+alarm and archive+alarm monitors. And even that only with the option

-archive. As far as I remember without looking at the code, alarm monitors are

handled within the gateway: The gateway simply drops monitor events to

alarm-only clients when the alarm status did not change. This was one of the

changes in the recent version. I requested that because setting the mask in the

command line was not transparent enough.

Dirk

Ralph Lange wrote:

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

--
Dr. Dirk Zimoch
Paul Scherrer Institut, WBGB/006
5232 Villigen PSI, Switzerland
Phone +41 56 310 5182

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System