| 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: asyn or caput rate limits? |
| From: | Michael Davidsaver <[email protected]> |
| To: | "Brown, Garth" <[email protected]>, "'[email protected]'" <[email protected]> |
| Cc: | "Gang Huang \([email protected]\)" <[email protected]>, "Carlos Serrano \([email protected]\)" <[email protected]>, "Larry Doolittle \([email protected]\)" <[email protected]>, "Ratti, Alessandro G" <[email protected]>, "Vamsi Vytla \([email protected]\)" <[email protected]> |
| Date: | Sun, 30 Apr 2017 18:27:49 -0400 |
On 04/29/2017 05:54 PM, Brown, Garth wrote:
>>>> for tag in range(2, 130):
> ... print tag
> ... epics.caput('RFS2:B15:SHELL_0_DSP_TAG_W', tag)
This client design will *always* have a risk of dropping put values.
In fact this is part of the design of Channel Access, asyn, and the
EPICS database to avoid unbounded queue sizes. If you can't tolerate
lose of put values then I think you'll need to address rate limiting at
the client/sender end.
Simply adding 'wait=True' to caput() will ensure that the client will
not send put requests faster than the server/IOC can process them. This
will work the same with and without ASYN_CANBLOCK on the server end.
http://cars9.uchicago.edu/software/python/pyepics3/overview.html#epics.caput
http://cars9.uchicago.edu/software/python/pyepics3/pv.html#put-with-wait-put-callbacks-and-put-complete