EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Delays in receipt of CA monitors
From: [email protected] (Jeff Hill)
To: "john sinclair" <[email protected]>, "Peregrine M. McGehee" <[email protected]>
Cc: <[email protected]>
Date: Fri, 10 Dec 1999 10:58:53 -0700
> 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
> scenario, 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.
>

Actually, this (CA monitor flow control induced loss of intermediate
state changes, but not the final value) was not Peregrine's problem
He was seeing a situation where monitors were occasionally late arriving
by several seconds, but no intermediate monitors (as determined by
timestamps) were discarded.

Note however that some 90% of Peregrine's problems disappeared when our
ancient GTA era cabletron hub based Ethernet network was partly upgraded
to a switched Ethernet network, and I fear that the remaining 10%
has not been recharacterized, so we need to be careful about assuming
that our current problems behave the same as our other 90% did.

Jeff



References:
Re: Delays in receipt of CA monitors john sinclair

Navigate by Date:
Prev: Re: Delays in receipt of CA monitors Peregrine M. McGehee
Next: RE: CA monitors...Update Jeff Hill
Index: 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Delays in receipt of CA monitors john sinclair
Next: Re: Delays in receipt of CA monitors john sinclair
Index: 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·