Experimental Physics and
Industrial Control System

"leo dalesio" <[email protected]> · Tue, 14 Mar 2000 15:37:40 -0500

A reason that the name resolution may be slow is that there is limited idle
time in the IOCs. As the name server is the lowest priority, a highly loaded
CPU could take a long time to respond to a large client that is trying to
connect.

WIth the name server at the highest priority, you will find the IOC, but the
connection will not be made or serviced, as channel access clients will then
be the lowest priority.

If you change the priority of the name server task from the lowest to the
highest, you significantly change the degradation mode of the system. With
the priority inverted, you can starve out the scan tasks with a network
problem that is broadcasting trash. If you are running any interlocks in
your IOC, or any other equipment critical IO, you may want to avoid running
in this configuration. If the names are valid and there is no problem on the
network, this is unlikely to cause more than some timing scew - we were
measuring 10K name resolutions per second on a 68040 (perhaps it was a
68020 - it was measured long ago).

An alternative to running the name server at the highest priority, would be
to either use a gateway (which creates a cache of connected channels at the
host level), or use a name server as the primary means of resolution - then
there is only local network traffic and the name server CPU utilization as
issues. This also relieves a source of network peaks that occur when large
clients are started  - like an archiver or alarm handler that attaches to
most channels in the system.

If the IOC were nothing but an IO multiplexor, one might consider inverting
the priorities - otherwise, consider the potential failure modes as well as
less obvious things like the frequency of a PID controller.

    Bob

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System