EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  <19971998  1999  2000  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  <19971998  1999  2000  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: flaky IOC problems at Jefferson Lab
From: [email protected]
To: [email protected]
Date: Tue, 07 Jan 97 20:59:16 -0500
>1) We have not experienced the CAMAC driver failure that is occurring
>at CEBAF. To the best of my knowledge CEBAF is using a different CAMAC driver

No, this is the LANL version of the driver causing trouble.  However, we may
be the only site running a large number of serial highways at 5MHz. The
LANL driver's error handling is much heavier weight than the original
CEBAF design, partly because of support for LAM's.

>Note that the efficiency of the name resolution activity was improved
>in 3.12 at some point (by changing a time constant). Perhaps Marty's numbers 
>do not agree with what CEBAF has observed because he is using a more recent 
>version of the code.

We are running 3.12.2.

>Note that the CA client lib _WILL_ recover in the rare circumstances when 
>this occurs if the operator is willing to wait for the full duration of 
>the timeout. 

We are seeing hung behavior persisting for a MUCH longer time than 80 seconds,
probably indicating that we encounter this timeout multiple times for a
single MEDM screen. (Question: how many names are sent in 1 packet?)

>(or a faster CPU that is less than 80% loaded)

I get tired of this response, but here's the reply again: it would cost the
equivalent of 2+ manyears of effort to replace all 60+ of our CPU's, or to 
double their number. (Note that APS is of comparable size to Jefferson labs and
uses twice as many CPU's; I'm not yet desparate enough to propose a 1/4 M$ 
upgrade.

I think the best commendation I've heard is to raise the CA TCP task up in
priority.  Can anyone think of any down side to this, other than compromising
the real time nature (mythical) of the lower priority scan tasks?  If this
is safe, I can live with the synchronous connect problem.

Thanks for all the discussion,

Chip



Replies:
Re: flaky IOC problems at Jefferson Lab Jeff Hill
References:
Re: flaky IOC problems at Jefferson Lab Jeff Hill

Navigate by Date:
Prev: Re: flaky IOC problems at Jefferson Lab Jeff Hill
Next: RE: flakey IOC problems at Jefferson Lab Eric Bjorklund, NPSM
Index: 1994  1995  1996  <19971998  1999  2000  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: flaky IOC problems at Jefferson Lab Jeff Hill
Next: Re: flaky IOC problems at Jefferson Lab Jeff Hill
Index: 1994  1995  1996  <19971998  1999  2000  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 ·