Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Subscription / first update
From: Ralph Lange <ralph.lange@gmx.de>
To: EPICS V4 Developers <epics-pvdata-devel@lists.sourceforge.net>
Cc: EPICS Core-Talk <core-talk@aps.anl.gov>
Date: Thu, 14 Jan 2016 13:23:08 +0100
The issue with subscriptions and first updates
========================================

This issue applies to monitor subscriptions to ANALOG values that use a DEADBAND technique to limit the update rate, e.g. CA monitors to EPICS database records of analog type that use MDEL.

The specification (or documentation) says a client gets the current value on connection, then updates whenever the value leaves a configured deadband around the value last sent.

The EPICS database uses the cache of the "value last sent" once per record instance. The first client will correctly get the current value, then updates when the values leaves the deadband. Additional clients will get the current value, then updates when the values leaves the deadband of the first client's last update. This effectively changes the deadband for the second update of additional clients to be anywhere between zero and twice the configured deadband.

In most cases, the effects are not prominent. For any values that change frequently, there's a short oddity right after connecting, then everything is in sync across all clients.

For slowly changing channels, however, that first update interval of additional clients can last minutes or longer. During that time (i.e. until the first client gets a new update), any additional newly connecting client will show a different value. I have seen situations (special synchrotron operation mode with extremely good lifetime) where a handful of panels on screens in the main control room where all showing different values for the same prominent PV (beam current).

Conceptually, there are two ways out of this:

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.

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?

Cheers,
~Ralph

Replies:
Re: Subscription / first update Andrew Johnson

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