[email protected] wrote:
> >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.
Have you verified connect performance problems for:
o after upgrading to 3.12.2
o 2000 channels
o CA server at default priority levels
o CAMAC in normal state
o 80% loaded mv167
We have not seen a problem here when the first 4 conditions are true.
I need to experiment with condition 5.
>
> >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?)
>
No doubt that it will try to reconnect (and therefore time out multiple
times). Also, the default (or configured) TCP connect sequence timeout on
the hp systems may be different.
> 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.
>
This has not been tried. I dont know of any reason why CA would fail
if you did this. Your IOCs may be less immune to increasing network
load in this situation (compounded when CPU loading is high). Some of your
application specific database logic may behave differently when interrupted
by ca during a scan. Also, this will make your systems different from other
installations and therefore perhaps it will be more difficult to diagnose
any problems that may occur at your site?
I am looking at a non-blocking connect implementation. A patch on
a branch off of 3.12.2 is possible if we go ahead with the change.
Would you (or anyone else) use this patch?
Jeff
--
______________________________________________________________________
Jeffrey O. Hill Internet [email protected]
LANL MS H820 Voice 505 665 1831
Los Alamos, NM 87545 USA FAX 505 665 5107
- Replies:
- Re: flaky IOC problems at Jefferson Lab watson
- References:
- Re: flaky IOC problems at Jefferson Lab watson
- Navigate by Date:
- Prev:
RE: flakey IOC problems at Jefferson Lab Eric Bjorklund, NPSM
- Next:
Re: flaky IOC problems at Jefferson Lab Marty Kraimer
- Index:
1994
1995
1996
<1997>
1998
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 watson
- Next:
Re: flaky IOC problems at Jefferson Lab watson
- Index:
1994
1995
1996
<1997>
1998
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
|