Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: Subscription / first update
From: Andrew Johnson <anj@aps.anl.gov>
To: Ralph Lange <ralph.lange@gmx.de>, EPICS V4 Developers <epics-pvdata-devel@lists.sourceforge.net>
Cc: EPICS Core-Talk <core-talk@aps.anl.gov>
Date: Thu, 14 Jan 2016 11:50:50 -0600
Hi Ralph,

On 01/14/2016 06:23 AM, Ralph Lange wrote:
> Either, the deadband algorithm (including the last value cache) is done
> per client - this is what happens when you use the 3.15 server-side
> plugin that does deadband limitation. This guarantees correct deadband
> behavior for each client, but makes the across-client situation worse:
> different panels showing the same PV will *always* show different values.

My discomfort with per-client deadbands like this is that each client
needs to know how big its deadband should be, and gets no hint at all
from the record. With the existing IOC deadbands, the database designer
can set 2 different deadband sizes for regular and archive monitors.

> Or - and that would be my suggestion - the first update that clients
> receive is redefined as being the cached last value that the first
> client of the same subscription received. That way, all additional
> panels that you open will always show the same value as the first
> client, even across Gateways. Also, the effective deadband for second
> updates to additional clients will be between zero and the configured
> value, and never larger than configured as in the current situation.
> 
> Would that be something to change in 3.16, and follow in V4?

The behaviour we get at the moment is a direct result of the fact that
the record does the deadband calculations and knows nothing about who is
monitoring its VAL field, while RSRV takes care of the monitoring but
knows nothing about deadbands. When a new client sets up a monitor, RSRV
sends the first update using the current value from the field to be
monitored; the new client won't get another value update until the
record's deadband calculation next triggers, at which point RSRV again
sends out the current contents of the VAL field to all monitoring clients.

The dbAccess code currently has no idea which fields of a record hold
the cached values or the deadband sizes (remember some records have 2
deadbands), so to implement your suggestion we'd have to change the
record type API in some way, and implement the necessary changes in all
record types that implement monitors with deadbands.

Hmm, does pvAccess even have the concept of separate event types, such
as archive monitors? If not I guess an alternative would be to provide
separate fields for the deadbanded values, which would have to be a
structure containing both the value and its timestamp. This gives
control of the deadband sizes back to the database designer, and the
choice of which deadband to use to the client. This approach would
implement the behaviour you're looking for...

- Andrew

-- 
There are only two hard problems in distributed systems:
  2. Exactly-once delivery
  1. Guaranteed order of messages
  2. Exactly-once delivery
 -- Mathias Verraes

Replies:
Re: Subscription / first update Michael Davidsaver
References:
Subscription / first update Ralph Lange

Navigate by Date:
Prev: Subscription / first update Ralph Lange
Next: Re: Subscription / first update Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019 
Navigate by Thread:
Prev: Subscription / first update Ralph Lange
Next: Re: Subscription / first update Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019 
ANJ, 22 Jan 2016 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·