EPICS Home EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

Format page
for printing


Search Tech-talk
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: [Fwd: Re: Does DISP work for DB OUT links? Related question]
From: Marty Kraimer <[email protected]>
To: [email protected]
Date: Wed, 03 Sep 2003 08:00:05 -0500
A few more thoughts on this topic.

Again the issue is what to do when a put to an asynchronous record occurs when the record has PACT TRUE, i.e. an asynchronous operation has started but is not complete.

I think the messages discussed three separate but related topics.

1) Should puts to a record with PACT TRUE be queued or cached.
2) If the answer is caching should the cached value be kept in the record or stored elsewhere.
3) If cached values are placed in the record then monitors should be based on the value sent to hardware not on the cached value.


A few comments seemed to imply that queuing puts is the best thing to do. But is this true? Consider a couple of examples:

A GUI has a slider attached to an aoRecord. Rapidly moving the slider can generate CA puts at a very rapid rate. Assume for example that 100 puts/second are generated and the user does that for 5 seconds. Also assume that the aoRecord is asyn and requires .5 seconds to complete an asyn operation. If puts are queued then after the slider stops moving there will be almost 500 puts queued. These will take about 250 seconds to complete. If puts are cached, however, it will only take about .5 seconds for the output to go to the last value of the slider.

A magnet is being controlled by some control algorithm. Assume the control algorithm can run at a 10 hertz rate, i.e. it generates an output value every .1 seconds. Assume the output goes to an asyn aoRecord that takes .2 seconds to complete. If outputs are queued, then the queue will grow without bound but even worse the delay between the requested output and the actual output also grows without bound. If puts are cached then each output request does experience a .2 second delay but it is bounded.

I think that caching rather than queuing is the correct behavior for asyn records for two reasons. 1) It is probably the behavior most often desired, and 2) implementing queueing is a "heavyweight" operation.

Assuming caching the next question is where to store the cached values. Storing them in the record is certainly the easiest because the record already has a place to put the values.

Assuming the cached values are put in the record the last issue is how to make monitors provide the value sent to hardware rather than the cached value. Currently this is not done, i.e. it is a bug. The message I sent yesterday proposed a solution that works at least for ao, bo, mbbo, and longout records.

The above discusses the behavior of individual records. Time Mooney discussed the problem of a set of records that implements some algorithm.

Tim Mooney made the comment:

> And it doesn't end there, of course.  The effects of outside interference
> in asynchronous record processing can carry over to sabotage algorithms a
> database may be trying to execute, if records in the database are
> asynchronous.
> Generally, one would like to be able to run a database algorithm with
> either
> synchronous or asynchronous records, because it normally is not the
> database
> designer, but the end user, who chooses the I/O devices.  This doesn't
> always
> work because records can behave much differently with asynchronous I/O
> devices
> than they would with synchronous devices.  I have databases thoroughly
> littered
> with records whose only purpose is to try to defend against value
> changes from
> CA clients during database-initiated record processing.
>
> No one would suggest that synchronous records should have to defend
> their fields
> against outside interference during processing.  I think the objective of
> asynchronous processing rules should be to approximate, as closely as is
> practical, the relatively safe environment enjoyed by synchronous records.
>
> I think EPICS should never write to any record while PACT==1.  (I'd like
> to say that scanLock should persist through the I/O-wait period of
> asynchronous
> processing, so that dbPutField could not modify any field in a lockset
> while
> asynchronous processing was going

I can see Tim's desire. Maybe do something like the following:

Extend DISP to have the following meaning:

DISP = (0,1,2) => (puts OK, puts OK unless PACT is TRUE, puts OK always)


Marty

Replies:
Re: [Fwd: Re: Does DISP work for DB OUT links? Related question] Marty Kraimer
Re: [Fwd: Re: Does DISP work for DB OUT links? Related question] Benjamin Franksen
References:
[Fwd: Re: Does DISP work for DB OUT links? Related question] Marty Kraimer
Re: [Fwd: Re: Does DISP work for DB OUT links? Related question] Marty Kraimer
Re: [Fwd: Re: Does DISP work for DB OUT links? Related question] Brian Bevins
Re: [Fwd: Re: Does DISP work for DB OUT links? Related question] Marty Kraimer
Navigate by Date:
Prev: RE: Problem with seq 2.0.4 Carl Lionberger
Next: RE: Problem with seq 2.0.4 Mark Rivers
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 
Navigate by Thread:
Prev: Re: [Fwd: Re: Does DISP work for DB OUT links? Related question] Marty Kraimer
Next: Re: [Fwd: Re: Does DISP work for DB OUT links? Related question] Marty Kraimer
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 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·