Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · 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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System