Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Wed, 9 Apr 1997 12:32:29 -0600

Hello all,

Sorry about the late reply - I have been enjoying a week and 2 days
vacation.

----------
> From: Alan K Biocca <[email protected]>
> To: [email protected]
> Subject: Re: ioc re-connect problem
> Date: Monday, April 07, 1997 9:56 AM
> 
> We occasionally experience similar problems. I believe that Al Robb
noticed
> this behavior and did something in his sequencer to compensate. Not
pretty.
> 
> I've suspected there are some subtle reconnect bugs, 

CA is designed to reconnect transparently and nearly instantaneously
in all circumstances where:
o The client is able to see beacons from the server
o The server is able to see the client's search requests

I am unaware of any outstanding problems with 3.12 EPICS in
this area. Please provide additional details about the subtle 
reconnect bugs you have seen.

> and we have spent time
> on the beaconing system since it causes a similar problem - if beacons
> aren't working correctly (like not getting through the router due to
> misconfiguration), and connectivity is lost, rebooting an UNINVOLVED
crate
> can fix the problem since it causes all unconnected channels to be
> re-searched.
> 
> The problem seems to be that unconnected channels give up at some point
and
> never retry. 

If CA does not find a channel within some reasonable (i.e. very long time
out) then 
it will stop searching until:

o It sees a new server beacon
o It sees that the period of an existing server beacon has changed
o the client side tool creates a new channel

> While that might be the desired behavior, I think I would set
> the max-retry to a different value. Perhaps this is easily configurable
in
> some version, it didn't seem to be when we looked (3.12?). 

The retry time out is a compile time parameter and not an environment
parameter. Since CA will always connect/reconnect  when it sees the beacon
then providing the ability to run time configure the length of this long
time out 
did not (during the design cycle) appear to be that important.

> Since the retry
> should only generate a broadcast packet (for the few unconnected
channels)
> every N minutes this would be acceptable for us. It would be nice to set
> the 'global default' in the compile and be able to adjust the individual
> client value in an environment variable. It should clamp to a minimum
value
> (say 1 minute) and a zero value would disable it (no retrys after initial
> series).
> 

I could add environment variables for the following:

1) turn on/off search retry suspension after some delay expires
	(pending the occurrence of a new server beacon on the LAN)
2) adjust the length of time before search retries are suspended
	(pending the occurance of a new server beacon on the LAN)
3) adjust the search retry interval final plateau (used before search 
	retries are suspended)

The negatives are:
1) I have to write the code
2) EPICS become more complex to configure
3) Your LAN may see additional (site configurable) broadcast messages 
4) In situations where the server beacons do not get through (are
incorrectly
	configured) the max delay from when the server is available to when
	the client actually reconnects will be similar to the delay specified 
	in (3) above.

Comments?

Jeff
______________________________________________________
Jeffrey O. Hill           Internet     [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System