g+
g+ Communities
Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
<== Date ==> <== Thread ==>

Subject: RE: CAC problem between RTEMS and vxWorks
From: "Hill, Jeff" <johill@lanl.gov>
To: Dirk Zimoch <dirk.zimoch@psi.ch>
Cc: EPICS tech-talk <tech-talk@aps.anl.gov>
Date: Tue, 25 Sep 2012 01:03:25 +0000
Hi Dirk,

> Jeff, maybe CA should "clean up" the stale sockets instead of waiting
> for TCP to do that (if possible).
>

Currently, the vxWorks system manager can, globally, adjust the timeout 
for such stale circuits, And furthermore I could add a new configuration 
environment variable to CA that sets this parameter specifically for CA 
circuits, but we proceed carefully on this path. Setting this type of 
timeout too short can cause a large EPICS system to not be robust during
periods of network congestion. For example, we prefer for the system to 
recover quickly if the main switches encounter a power glitch.

Jeff

> Dirk
> 
> >
> >> -----Original Message-----
> >> From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-
> bounces@aps.anl.gov]
> >> On Behalf Of Wesley Moore
> >> Sent: Wednesday, September 19, 2012 10:19 AM
> >> To: EPICS tech-talk
> >> Subject: CAC problem between RTEMS and vxWorks
> >>
> >> All,
> >>
> >> I'm having issues with a RTEMS client (3.14.11) accessing PVs from a
> >> vxWorks IOC (3.14.8.2).  When the RTEMS IOC is rebooted, sometimes it
> >> doesn't reconnect to the other IOC.  Even after connecting, I'm often
> >> getting timeouts on RTEMS and can't seem to maintain a solid connection
> >> between the two.
> >>
> >> # timeouts on RTEMS client IOC
> >> CAC: Unable to connect because "Connection timed out"
> >> CA.Client.Exception...............................................
> >>     Warning: "Virtual circuit disconnect"
> >>     Context: "iocfel8.acc.jlab.org:5064"
> >>     Source File: ../cac.cpp line 1145
> >>     Current Time: Wed Sep 19 2012 11:52:27.183784942
> >> ..................................................................
> >>
> >> After reboots, It stacks up new socket connections which isn't helping
> >> matters.
> >>
> >> # casr on vxWorks IOC
> >> TCP 129.57.214.101:1024(): User="rtems", V4.11, 4 Channels, Priority=0
> >> TCP 129.57.214.101:1025(): User="rtems", V4.11, 4 Channels, Priority=0
> >> TCP 129.57.214.101:1026(): User="rtems", V4.11, 4 Channels, Priority=0
> >> TCP 129.57.214.101:1027(): User="rtems", V4.11, 4 Channels, Priority=0
> >> TCP 129.57.214.101:1028(): User="rtems", V4.11, 4 Channels, Priority=0
> >> TCP 129.57.214.101:1029(): User="rtems", V4.11, 4 Channels, Priority=0
> >> TCP 129.57.214.101:1030(): User="rtems", V4.11, 4 Channels, Priority=0
> >> TCP 129.57.214.101:1031(): User="rtems", V4.11, 4 Channels, Priority=0
> >>
> >>
> >> Any help is greatly appreciated.
> >>
> >> Wesley
> >
> >



References:
CAC problem between RTEMS and vxWorks Wesley Moore
RE: CAC problem between RTEMS and vxWorks Hill, Jeff
Re: CAC problem between RTEMS and vxWorks Dirk Zimoch

Navigate by Date:
Prev: Re: DHCP/BOOTP configuration for EPICS with RTEMS Bruno Seiva Martins
Next: Microsoft managed code CLI C++ and EPICS Mark Clift
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
Navigate by Thread:
Prev: Re: CAC problem between RTEMS and vxWorks Benjamin Franksen
Next: Bug on autosave for the ULONG type array Kim, Kukhee
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·