Hi Jay,
Yes, I am running on Windows XP.
I wonder if it could be an antivirus problem or something.
If you look in task manager when you run caget, is it CPU
bound during those 5 seconds? Do any other processes begin using a lot of CPU
time during that 5 second interval?
Since Jeff mentioned TCPView I downloaded that for Windows
and it looks like a very useful utility.
Mark
From:
[email protected] [mailto:[email protected]] On Behalf Of Jay Steele
Sent: Wednesday, February 16, 2011
5:07 PM
To: [email protected]
Subject: RE: cygwin and DOS caget,
caput running slow at end due toca_context_destroy(), option to speed up
execution?
Hi Mark and Jeff
Are you guys running
Windows XP? My results on my Windows XP computer are different than yours for
some reason. I measure about 5 seconds to run caget and caput. Here’s
more information.
1. No significant delay using MEDM GUI CA
client on the same Windows XP computer to get or modify PV values on VxWorks
IOC.
2. For caget and caput, 5 second delay
occurs inside function epicsThreadPrivateGet called from ca_context_destroy to
access PV records on VxWorks IOC.
I could
speculate that there is something wrong with my EPICS makefiles and I’m
not using the correct option somewhere for the cygwin build, but I get the
similar results (delay ~5 seconds) with the pre-compiled Win32 Extension caget
function. Could there be some Windows XP environmental variable or setting for
handling threads that I need to set?
When I add some print
statements to track where the cygwin caget code is stalling, the code stalls
for the 5 seconds at the last pthread_getspecific call inside
epicsThreadPrivateGet. For some reason, the initial call to pthread_getspecific
within epicsThreadPrivateGet function launches a succession of calls to
epicsThreadPrivateGet. I cannot find where this recursive logic is.
Here’s the output. I get the same output when I run caget to access a PV
record field from the softIOC running on the same Windows computer, but without
the ~5 second delay.
Epics/base/src/ca/access.cpp -
ca_context_destroy(), calling epicsThreadPrivateGet with id = 5382720
Epics/base/src/libCom/osi/os/posix/osdThread.c
- epicsThreadPrivateGet(), id=5382720, calling assert
Epics/base/src/libCom/osi/os/posix/osdThread.c
- epicsThreadPrivateGet(), calling pthread_getspecific
Epics/base/src/libCom/osi/os/posix/osdThread.c
- epicsThreadPrivateGet(), id=5380552, calling assert
Epics/base/src/libCom/osi/os/posix/osdThread.c
- epicsThreadPrivateGet(), calling pthread_getspecific
Epics/base/src/libCom/osi/os/posix/osdThread.c
- epicsThreadPrivateGet(), id=5380552, calling assert
Epics/base/src/libCom/osi/os/posix/osdThread.c
- epicsThreadPrivateGet(), calling pthread_getspecific
Epics/base/src/libCom/osi/os/posix/osdThread.c
- epicsThreadPrivateGet(), id=5380552, calling assert
Epics/base/src/libCom/osi/os/posix/osdThread.c
- epicsThreadPrivateGet(), calling pthread_getspecific
Epics/base/src/libCom/osi/os/posix/osdThread.c
- epicsThreadPrivateGet(), id=5380552, calling assert
Epics/base/src/libCom/osi/os/posix/osdThread.c
- epicsThreadPrivateGet(), calling pthread_getspecific
wait ~5 seconds . . .
Epics/base/src/libCom/osi/os/posix/osdThread.c
- epicsThreadPrivateGet(), id=5380552, calling assert
Epics/base/src/libCom/osi/os/posix/osdThread.c
- epicsThreadPrivateGet(), calling pthread_getspecific
Epics/base/src/ca/access.cpp -
ca_context_destroy(), calling epicsThreadPrivateSet
Epics/base/src/libCom/osi/os/posix/osdThread.c
- epicsThreadPrivateGet(), id=5380552, calling assert
Epics/base/src/libCom/osi/os/posix/osdThread.c
- epicsThreadPrivateGet(), calling pthread_getspecific
Cheers,
Jay Steele
From: Jeff Hill
[mailto:[email protected]]
Sent: Wednesday, February 16, 2011
2:15 PM
To: Jay Steele;
[email protected]
Subject: RE: cygwin and DOS caget,
caput running slow at end due to ca_context_destroy(), option to speed up
execution?
Hi Jay,
I don’t see this either, but I am
using only win32-x86 and win32-x86-mingw on my windows machines. The cygwin
posix emulation adds some additional layers around windows sockets to obtain
posix compatibility.
Ø the
majority of the execution time (4-5 seconds) seems to be spent running the
ca_context_destroy function
The ca_context_destroy will wait for the
tcp circuit shutdown handshake to finish before returning. You can watch this
with netstat or in GUIs like, for example on windows, tcpview. The GUI might
update the tcp state machine changes more rapidly as they are occurring.
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
From:
[email protected] [mailto:[email protected]] On Behalf Of Jay Steele
Sent: Wednesday, February 16, 2011
1:00 PM
To: [email protected]
Subject: cygwin and DOS caget,
caput running slow at end due to ca_context_destroy(), option to speed up
execution?
Hi
EPICS folks,
I’m running caget and caput utility functions from cygwin and DOS on a
Windows XP system to get and put data to a VxWorks IOC on the same subnet. I
would like to know if there is some option to help speed up the execution of
these utility functions. For both sets of utility functions, the majority of
the execution time (4-5 seconds) seems to be spent running the
ca_context_destroy function at the end. I don’t see this delay when
running caget and caput functions to get and put data to a Soft IOC running on
the same Windows XP computer. I don’t understand why there is such a
delay just to clean up at the end.
I’m using epics base v3-14-11 for cygwin and EPICS WIN32 Extensions
Version 1.40 (Build 40) for DOS.
Thanks,
Jay
Steele
Xradia
Corporation
The information in this email, including
any attachments, is confidential and intended only for the recipient(s) listed.
Any use of this email for any other purpose is prohibited. If you have received
this email in error, please notify me immediately by reply email, delete this
email, and do not disclose its contents to anyone.
The information in this email, including
any attachments, is confidential and intended only for the recipient(s) listed.
Any use of this email for any other purpose is prohibited. If you have received
this email in error, please notify me immediately by reply email, delete this
email, and do not disclose its contents to anyone.