Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Mon, 9 Feb 2009 11:32:58 -0700

> So my suggestion is: enable the historical behavior (using the
> original code?) to take effect with the proper environment variables.

These are some of the issues we were thinking about when the current
behavior was set. 
1) We don't want the configuration for the system to be too daunting. More
details have the bad side effect of more for new users to learn.
2) We want to minimize the impact for large facilities when a client is miss
configured.
3) Perhaps it's not a grievous hardship for a client with 1000 channels to
wait two minutes to connect if it has already been waiting for hours. At
least from an operational perspective that isn't likely to be a significant
impact? Most operational IOCs probably take quite a bit longer than two
minutes to boot, and connect times are instantaneous if the IOC is restarted
when the client is already connected.

I should add also that it just might be possible to improve the situation
for clients that were connected in the past, have been disconnected for a
long time, but who see the beacon, of the server (that they were originally
connected to) change when it boots. Maybe that enhanvcement would somewhat
reduce the need for another configuration parameter?

> I could even live with conditional compilation (-DCA_BEST_RESPONSE vs
> -DCA_MOST_STABILITY).

I suppose that if we need to limit use of a feature it would be better to do
it with the access security system rather than by using (build time)
obscurity (we are hopefully moving in the future to a binary install). Of
course calling AS from the CA client would be a completely new use of AS.

Jeff

> -----Original Message-----
> From: Steve Lewis [mailto:[email protected]]
> Sent: Wednesday, February 04, 2009 8:12 AM
> To: Jeff Hill
> Cc: 'Mark Rivers'; 'Andrew Johnson'; 'Core-Talk'
> Subject: RE: Very slow reconnection to medm after IOC reboot
> 
> At 6:46 PM -0700 2009/02/03, Jeff Hill wrote:
> >
> >...long discussion omitted...
> >
> >>  - How would we actually like it to behave in the future.
> >
> >Connect times should be as fast, and responsive to the appearance of a
new
> >IOC, as possible without impacting overall network stability, but I
> suspect
> >that you are not surprised to hear that answer. I am actually quite
> >malleable to suggestions on how we can improve performance, but system
> >stability must be guaranteed as our first priority.
> 
> '...first priority'? I disagree.
> 
> While I appreciate the need to allow large sites to ensure network
> stability *WITH PROPER CONFIGURATION* (and not too long ago SNS
> presented a convincing field case), we should also allow a
> knowledgeable EPICS administrator to configure a small test system to
> achieve the historical fast reconnect times.  Both scenarios are
> equally important.
> 
> So my suggestion is: enable the historical behavior (using the
> original code?) to take effect with the proper environment variables.
> I could even live with conditional compilation (-DCA_BEST_RESPONSE vs
> -DCA_MOST_STABILITY).

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System