EPICS Home

Experimental Physics and Industrial Control System


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

Subject: Re: Subscription / first update
From: Andrew Johnson <[email protected]>
To: Ralph Lange <[email protected]>, EPICS V4 Developers <[email protected]>
Cc: EPICS Core-Talk <[email protected]>
Date: Fri, 22 Jan 2016 15:26:47 -0600
Hi Ralph,

On 01/21/2016 08:53 AM, Ralph Lange wrote:
> This all increases my feeling that there's something more fundamentally 
> in need of a review in the current concept.
> 
> The database designer should be the one setting reasonable defaults (aka 
> hints) for deadbands, and we need at least two - no doubt about that. 
> Probably needed for all run-time fields: VAL, RVAL, ...

Not convinced about that last point, each field would then require
additional storage for two deadband sizes plus two copies of the last
value sent, thus blowing up most fields to 5 times their original size
(and that's without adding per-client deadband storage). I would say
that only fields designated in the DBD file as supporting deadbands
should get them — that may have been what you meant, but the DBD file
doesn't currently have anything to distinguish run-time fields.

> Clients should be able to override by setting specific deadbands - that 
> has been on the enhancement list for a long time.
> Clients should also be able to read the defaults (in a standard way) - 
> that might need a filter plug-in for CA and could be part of the NT 
> system for PVA.
> Obviously, the deadband defaults must be accessible (readable) through 
> the database API, so that the server can use them when clients do not 
> configure specific deadbands or ask for the defaults.
> 
> However, executing the deadband algorithm could be made part of the 
> server, not the database.

I see a major development needed to implement something like that in the
IOC. This could be done by adding a new DBF_STRUCT field type and
providing support code for each type of struct [that sounds a bit like
the support code in Marty's pvDatabase doesn't it?]. For deadbands the
struct would have members for the deadband size and the last-published
value; the record would provide an unfiltered value field plus as many
deadband structures as it felt necessary (or even an array of such
structures, but that would require dbLoad-time allocation of array
memory). Client-specified deadbands would be implemented using a
server-side filter on the unfiltered field.

> One thing that really breaks using the database for real-time 
> applications is that pushing the updates for *all* clients to a record 
> is done in the context of database processing. Any client adding a 
> subscription adds to the record's execution time, ruining attempts to 
> achieve reliable deterministic processing behavior.
> If the record only pushes one update to a single queue, and another 
> high-priority "broker" thread does the per-client multiplication and 
> deadband processing, wouldn't that make the record processing a lot more 
> deterministic? (That would work a bit like a local GW on top.)
> Of course, clients can subscribe to different fields, so the database 
> update must probably push a complete copy of the record's runtime 
> fields. 

The database doesn't quite work like that; currently the only way to
find out which fields might generate monitors when a record is processed
is to look for calls to db_post_events() in the record.c files. As a
result I don't think you need to store that complete copy, the current
code should already be deterministic as long as each call to
db_post_events() takes the same time (i.e. it always pushes every posted
value onto a queue for the broker to process and distribute, even when
no clients are currently monitoring this field).

Of course many records in today's IOCs don't have any monitors on them,
so this will slow down the IOC, and it would also break any IOCs with
subroutine records that currently take a look at their own MLIS field to
see if anyone is actually watching them (CA client detection). There
could also a problem when the field being monitored is a large array and
the IOC doesn't have much spare memory.

> The broker, however, could run on a different core using the 
> copy of the record data, so that nothing keeps the processing thread 
> from continuing. Actually, two modes seem possible:
> Optimized, where the push happens when there's at least one subscription 
> to a record.
> Deterministic, where every processing pushes an update (resulting in a 
> stable execution time), and the broker drops updates with no subscription.

To be honest I don't really like the deterministic broker thing, unless
it can be made optional somehow. If the effect of adding one more CA
client to a record could break your application, maybe you could just
put a real gateway in front of the IOC?

Support for DBF_STRUCT field types though is a different matter, but
adding them wouldn't be a small job...

- 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

References:
Subscription / first update Ralph Lange
Re: Subscription / first update Andrew Johnson

Navigate by Date:
Prev: Jenkins build is back to normal : epics-base-3.14-sol #13 APS Jenkins
Next: Autosave called epicsMessageQueueSend with opMsgQueue==NULL Henrique Almeida
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Subscription / first update Michael Davidsaver
Next: Build failed in Jenkins: epics-base-3.14-sol #12 APS Jenkins
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024