Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Tue, 31 May 2011 09:17:35 -0600

> Jay is seeing 5 second delays when running caget, and
> he says he has tracked it down to ca_context_destroy().

Most likely these delays occur when the socket is closed and the tcp/ip
circuit's shutdown handshake is executed, but there might also be an issue
in the ca client library. Perhaps there are some subtle incompatibilities
between the IP kernel variants during this shutdown. The next step might be
to run wire shark and watch the low level TCP/IP handshake during shutdown,
with the packet timestamps enabled in the output. That would help to fault
isolate between an issue in the ca client library and an issue in the IP
kernel implementation.

Of course, more optimal performance can be obtained by writing a specialized
ca client that opens N channels, fetches N values, and then closes the N
channels. This will allow the circuit creation/shutdown overhead and process
creation/shutdown overhead to be amortized over the N channels.

Jeff
______________________________________________________
Jeffrey O. Hill           Email        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Mark Rivers
> Sent: Tuesday, May 31, 2011 5:45 AM
> To: Ralph Lange; tech-talk
> Subject: RE: caget command holds for more than 10 seconds
> 
> I am posting some messages from a thread Jay Steele, Jeff Hill and I had
> earlier this month.  Jay is seeing 5 second delays when running caget, and
> he says he has tracked it down to ca_context_destroy().  He sees it with
> both the Cygwin and WIN32 builds, but not to all IOCs.
> 
> Mark
> 
> ----- Original Message -----
> From: "Mark Rivers" <[email protected]>
> To: "Jay Steele" <[email protected]>, "Christian Roehrig"
> <[email protected]>
> Sent: Wednesday, May 4, 2011 3:48:08 PM
> Subject: RE: cygwin and DOS caget, caput running slow at end due
> toca_context_destroy(), option to speed up execution?
> 
> Jay,
> 
> The plot thickens.  I just tried the same comparison as you.  I am
> running caget on my XP machine.
> 
> Here is what I get when I access a PV on a vxWorks IOC.  This is also
> 5.4.2, and is almost certainly the same BSP as Chris.
> 
> C:\Temp>echo 15:42:31.61
> 15:42:31.61
> 
> C:\Temp>.\caget_win32-x86.exe 13IDA:m1
> 13IDA:m1                       -0.25
> 
> C:\Temp>echo 15:42:31.75
> 15:42:31.75
> 
> 
> So it only took 0.14 seconds, very fast.
> 
> Now I access a PV on a remote Windows 7 machine.
> 
> 
> C:\Temp>echo 15:43:52.80
> 15:43:52.80
> 
> C:\Temp>.\caget_win32-x86.exe 13IDDPS1:cam1:Acquire
> 13IDDPS1:cam1:Acquire          Done
> 
> C:\Temp>echo 15:43:57.55
> 15:43:57.55
> 
> 
> So it took 4.75 seconds.  So my results are almost exactly the opposite
> of yours, I am getting fast access to vxWorks and very slow access to a
> remote Windows machine.
> 
> Mark
> 
> Hi Chris,
>      I see excessive delays (~5 seconds) when I use caget from a Windows
> XP computer to access EPICS PVs on the VxWorks IOC. I get much better
> results (~0.05 second) using caget from the Windows XP computer to access
> EPICS PVs on the soft IOC running on another Windows XP computer. Running
> caget from a LINUX computer to access EPICS PVs on VxWorks IOC also has
> minimal delay (~0.05 second).
> 
>      We are using the BSP (VxWorks version 5.5.2) for the VxWorks IOC that
> you provided to us some months ago. Have you ever run caget from a Windows
> computer to one of your VxWorks systems? If so, did you see the same ~5
> second delay?
> 
> Thanks,
> Jay Steele
> Xradia Corporation
> 
> Hi Mark,
>      I'm running Windows XP version 2002 service pack 3. When I run the
> test_caget.bat file on a Windows command shell to access a PV on a VxWorks
> IOC on the same subnet, I get the following:
> 
> C:\Program Files\EPICS WIN32 Extensions>echo 10:25:32.22
> 10:25:32.22
> C:\Program Files\EPICS WIN32 Extensions>caget "21:D3:SM:mx:ActPos"
> 21:D3:SM:mx:ActPos             5001.46
> C:\Program Files\EPICS WIN32 Extensions>echo 10:25:36.79
> 10:25:36.79
> 
> So, caget ran for 4.57 seconds on Windows with the caget executable
> provided with EPICS WIN32 Extensions Version 1.40 (Build 40).
> 
>      When I run the same test_caget.bat file on a cygwin command shell to
> access a PV on a VxWorks IOC on the same subnet, I get the following:
> 
> C:\Software\Software\UltraSPX_EPICS\test>echo 10:29:10.57
> 10:29:10.57
> C:\Software\Software\UltraSPX_EPICS\test>caget "21:D3:SM:mx:ActPos"
> 21:D3:SM:mx:ActPos             5001.46
> C:\Software\Software\UltraSPX_EPICS\test>echo 10:29:15.22
> 10:29:15.22
> 
> So, caget ran for 4.25 seconds on cygwin-x86 using the epics/base-3-14-
> 11/bin/cygwin-x85/caget executable. It is clear that the data is obtained
> right away, but then there is a delay returning from the caget function. I
> went through the code some weeks ago, and observed that the delay is due
> to the ca_context_destroy function.
> 
> The equivalent of caget that runs on the same Windows computer as part of
> the MEDM client to get PV data from the same VxWorks IOC does not have
> these delays.
> 
> Cheers,
> Jay Steele
> Xradia Corporation
> 
> 
> ________________________________
> 
> From: [email protected] on behalf of Ralph Lange
> Sent: Tue 5/31/2011 5:07 AM
> To: tech-talk
> Subject: Re: caget command holds for more than 10 seconds
> 
> 
> 10 seconds is the default timeout for channels that are not found.
> 
> Can you please show the command line you are using and its output? It
> would also be useful to know which system you are running caget on, and
> which version of EPICS you are using.
> 
> Thanks,
> ~Ralph
> 
> 
> On 31.05.2011 04:17 lailongwei wrote:
> 
> 	hi,
> 	  when I use caget A, though the data has been gotten, it holds for
> about ten sends untill the command exit.
> 	This cause problem when I need to caget four PVs, whose sampling at
> the same time is very important. How can I solve it.
> 	Thanks!
> 
> 	2011-05-31
> 
> ________________________________
> 
> 	lailongwei
> 
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System