Experimental Physics and
Industrial Control System

john sinclair <[email protected]> · Fri, 10 Dec 1999 11:53:27 -0500 (EST)

On Wed, 8 Dec 1999, Peregrine M. McGehee wrote:

> Here at the Low Energy Demonstration Accelerator we are seeing
> intermittent significant delays in the receipt of CA monitors. As these
> delays are large enough to trigger a hardware protection system that
> places the accelerator in a safe mode (e.g. turn the beam off) we have
> spent considerable time over the past months to understand this.
> 
> We don't yet understand the root cause and are asking if anyone has seen
> a similar effect. We realize that TCP is non-realtime but are concerned
> since these delays can as large as 3 to 10 seconds.
> 

	.
	.
	.

I believe this is to be expected. Jeff Hill explained to me at one time
that the channel access flow-control behavior can produce just these kind
of results. Channel access favors getting the most recent information to
an application over sending all intermediate information and this policy
is a very good one. Heartbeat applications, on the other hand, are not
well served by this behavior. It is easy to imagine that for a certain
senario, with the right amount of network loading, the client would miss
the event when the value is zero and receive the event when the value is
one (which would be the most recent info for this imagined case). This
behavior wouldn't last forever, but on rare occasions it might follow
this sequence long enough to trip the watchdog.

A question for tech-talk: Would the use of scan groups fix this? I
haven't yet any experience in using them.

John Sinclair
[email protected]
Oak Ridge National Lab
865-576-6362   865-574-1268 (fax)

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System