Doug,
I didn't write caSnoop, and also don't maintain it. For detailed questions
contact Ken Evans who is its author.
As for the strip charting client loosing its connection to caSnoop one
possibility might be that the caSnoop server is CPU saturated printing
messages and therefore was not responsive to its clients, and this might
cause them to disconnect.
Here is a general comment on network issues. I am not familiar with your
situation, but I should add that some robustness improvements have been
introduced in EPICS R3.14. Some of these changes showed up in early releases
of R3.14 and other were introduced as late as R3.14.6.
Here are the two situations I am aware of that have caused global EPICS
communications issues with R3.13.
1) Configuring particularly low values into EPICS_CA_CONN_TMO. This could
cause the load introduced by connect/reconnect cycles to grow to
unreasonable levels with a potential for unstable feedback.
2) If you have a large system with many clients and servers it has been
reported that it can take awhile for the system to recover if you turn off
the backbone switches for longer than EPICS_CA_CONN_TMO, but don't at the
same time turn off the hosts for the clients and servers.
There are changes in R3.14.6 which address both of the above issues.
I am always interested in receiving feedback concerning the overall quality
of the EPICS communication infrastructure in large or small systems.
If you send a quick summary on what symptoms are observed there I might be
able to comment further.
Jeff
> -----Original Message-----
> From: Doug Summers [mailto:[email protected]]
> Sent: Tuesday, November 23, 2004 12:04 PM
> To: 'Jeff Hill'
> Cc: [email protected]
> Subject: caSnoop question
>
> Hi Jeff/all,
>
> I've been doing some disconnected channel analysis using caSnoop, and
> I'm
> confused by a portion of the output I've been seeing. I am getting
> disconnected channel outputs in both the launching xterm and mixed in
> the
> caSnoop stats that I think are not related to our network traffic
> problems.
> It looks like caSnoop and/or the stripchart used for caSnoop are either
> not
> configured correctly and/or are interjecting some problems of their own.
> I'm not suggesting our problem is caSnoop...I am making good progress
> with
> the tool, but want to understand what caSnoop is adding into the mix.
> Can
> anyone explain what's happening (and maybe tell me how to
> minimize/eliminate
> these effects)? Here's our caSnoop terminal output messages:
>
> requestDescRecord: ca_search_and_connect: CaSnoop.DESC
> requestDescRecord: ca_search_and_connect: CaSnoop.DESC
> requestDescRecord: ca_search_and_connect: r431.DESC
> requestDescRecord: ca_search_and_connect: r432.DESC
> requestDescRecord: ca_search_and_connect: r433.DESC
> requestDescRecord: ca_search_and_connect: r434.DESC
> requestDescRecord: ca_search_and_connect: r435.DESC
> requestDescRecord: ca_search_and_connect: r436.DESC
> requestDescRecord: ca_search_and_connect: r438.DESC
> Strip_go: waiting for connection...
>
> StripDAQ connect_callback: IOC unavailable for CaSnoop.individualRate
> CA.Client.Exception...............................................
> Warning: "Virtual circuit disconnect"
> Context: "kepuhi:51425"
> Source File: ../cac.cpp line 1147
> Current Time: Tue Nov 23 2004 08:40:42.970034702
> ..................................................................
> StripDAQ connect_callback: IOC unavailable for CaSnoop.requestRate
>
> Tue Nov 23 08:40:43 HST 2004
> medmCAExceptionHandlerCb: Channel Access Exception:
> Channel Name: Unavailable
> Native Type: Unavailable
> Native Count: 0
> Access: Unavailable
> IOC: Unavailable
> Message: Virtual circuit disconnect
> Context: kepuhi:51425
> Requested Type: TYPENOTCONN
> Requested Count: 0
> Source File: ../cac.cpp
> Line number: 1147
>
> StripDAQ_request_disconnect: ca_clear_channel: CaSnoop.requestRate
> StripDAQ_request_disconnect: ca_clear_channel: CaSnoop.DESC
> StripDAQ_request_disconnect: ca_clear_channel: CaSnoop.individualRate
> StripDAQ_request_disconnect: ca_clear_channel: CaSnoop.DESC
> StripDAQ_request_disconnect: ca_clear_channel: r431.existTestRate
> StripDAQ_request_disconnect: ca_clear_channel: r431.DESC
> StripDAQ_request_disconnect: ca_clear_channel: r432.existTestRate
> StripDAQ_request_disconnect: ca_clear_channel: r432.DESC
> StripDAQ_request_disconnect: ca_clear_channel: r433.existTestRate
> StripDAQ_request_disconnect: ca_clear_channel: r433.DESC
> StripDAQ_request_disconnect: ca_clear_channel: r434.existTestRate
> StripDAQ_request_disconnect: ca_clear_channel: r434.DESC
> StripDAQ_request_disconnect: ca_clear_channel: r435.existTestRate
> StripDAQ_request_disconnect: ca_clear_channel: r435.DESC
> StripDAQ_request_disconnect: ca_clear_channel: r436.existTestRate
> StripDAQ_request_disconnect: ca_clear_channel: r436.DESC
> StripDAQ_request_disconnect: ca_clear_channel: r438.existTestRate
> StripDAQ_request_disconnect: ca_clear_channel: r438.DESC
>
> When I look at the report stats from caSnoop (using the medm tool), I
> see
> these channels reported as disconnected (intermixed with our application
> channel stats). Are these disconnected references somehow inherent in
> the
> tool, or do we have a caSnoop configuration problem? Any advice would
> be
> appreciated.
>
> Thanks,
> Doug Summers
> W. M. Keck Observatory
> 808 885-7887
- References:
- caSnoop question Doug Summers
- Navigate by Date:
- Prev:
caSnoop question Doug Summers
- Next:
Re: caSnoop question Martin L. Smith
- 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:
caSnoop question Doug Summers
- Next:
Re: caSnoop question Martin L. Smith
- 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
|