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: No monitor refresh |
From: | "Mark Rivers" <[email protected]> |
To: | "Hinko Kocevar" <[email protected]>, <[email protected]> |
Date: | Fri, 14 May 2010 08:31:51 -0500 |
Hi Hinko, If I understand correctly, your hypothesis is that the
callbacks from the asyn driver to device support are happening, but that the
record is not processing, perhaps because the EPICS callback task running
scanIoRequest is not getting the CPU time it needs. With asyn 4-10 there is a simple way to test this. If
that hypothesis is true then the ring buffer will be overflowing, because more
than 10 callbacks happened without processing the record and removing values
from the ring buffer. If you force the record to process (use “dbtr
myRecord” or “dbpf myRecord.PROC,”1” at the IOC shell)
then you should see an error message about ring buffer overflow when the record
processes. If you do not see that error message then the hypothesis is
wrong. Mark From: Mark Rivers Hinko, I really don't think you need to worry about the size of the
ring buffer. 10 values is probably fine. The purpose of the ring
buffer is to prevent losing callback values that come very close together in
time. For example, consider a binary input device that is I/O Intr
scanned on both rising and falling transitions. If a short pulse, say 50
microseconds, occurs, we want to EPICS to process the record on both the rising
and falling edges. The ring buffer allows that, because although the
record won't process within 50 microseconds, both values will be in the ring
buffer and the record will process twice. On the other hand if the pulses
come too frequently then no size ring buffer will help if EPICS cannot process
the record fast enough on average. It sounds like your problem may be that some of
your callbacks are very CPU intensive. I run devices like the Acromag
IP330 16 channel ADC at more than 2,000 callbacks per second and it uses only
small fraction of the CPU. But those don't process the ai records at that
rate, it uses the asynInt32Average device support to average the readings between
periodic processing. Are you saying that if you slow down some of your devices
then all of the callbacks do run correctly? What is the total number of
callbacks per second in your system? Mark From: [email protected]
on behalf of Hinko Kocevar Hi Mark, |