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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: PyEpics speed |
From: | "Dalesio, Leo" <[email protected]> |
To: | Jeremy Iken <[email protected]>, "[email protected]" <[email protected]> |
Date: | Mon, 24 Jun 2013 15:39:37 +0000 |
Hi Jeremy,
From your pyEPICS call, there are a number of layers:
1) Your server (not sure which one this uses)
2) Channel Access server - 2-4 steps are what we would call EPICS comm time < 1 msec
network
3) Channel Access Client
4) EPICS database housing the device - this could have a scan time that could contribute to the delay
- - what is the SCAN field of the record you are getting?
5) EPICS Device Support - this could be immediate for register based devices to slow for GPIB
6) EPICS driver - this matches the time of the hardware and can either read ahead or on
demand and then wait for the hardware.
7) hardware - whatever the protocol response time there is to this - or time to
next trigger
For 200 msecs, the first place I would look is in the scan rate of the database record.
|