Experimental Physics and
Industrial Control System

Till Straumann <[email protected]> · Mon, 02 Feb 2009 11:03:16 -0800

Benjamin Franksen wrote:

On Thursday 29 January 2009 20:04, Andrew Johnson wrote:

It is currently very well-defined what the timestamp returned by a
DBR_TIME request through CA holds; it gives the value of the TIME field
of the record containing the PV, read atomically with the value and other
attributes that came with it.  A record's TIME field also has a
well-defined meaning; it indicates when that record was last processed
(although strictly speaking the behavior is record-type specific).  Thus
I disagree with your Subject: line; the timestamps provided with the
monitor are not actually wrong, they just don't necessarily reflect the
time when that PV data was stored.
[...]
I suggest that the place to fix that problem is in the Channel Archiver,
not in the IOC.

If I want to get the last time the record has been processed, I access the

VAL field. This is directly supported by it being the default if no field

name is given. Accessing any other field means I care for this field

specifically, not the record in general.

It certainly makes sense to insist on well-defined semantics for timestamps

(as for anything else, in fact). The current meaning ("time when record was

last processed") is well-defined, clear and simple. But so would be "time

when IOC was last booted". The question is: how useful are these meanings?

Obviously, the former is more useful than the latter, since it gives you

more detailed and more relevant information. So there are good reasons to

chose the latter over the former, if it can be implemented at a reasonable

cost (in memory, run-time, and development effort). I argue that "time when

field was last updated" is an even more (really much more) useful way to

define what the timestamp means and it is equally well-defined.

We had some discussion here between Ralph, Götz, and me, and we think that

it is possible to implement this in base at very reasonable cost, providing

complete backward compatibility (by default), and requiring no changes to

existing record support code (under moderate assumptions about what record

and device support do).

We propose to introduce a switch, one per IOC (one per record instance would

be possible, too, but probably overkill), which lets you select between

 (a) old behaviour (timestamp = last record process time)
 (b) new behaviour (timestamp = last update to field)
 (c) the maximum of (a) and (b) (timestamp = last update to field or
     last record process time if this has occurred later)

for all read accesses (ultimately calls to dbGet and CA monitors).

The default would be (a), so that compatible behaviour is guaranteed. The

default could be changed to (b) for future major releases. Whether (c) is

really useful is debatable, but I wanted to mention it as it would be cheap

to realize.

Our idea for an efficient implementation is based on the observation that in

a typical EPICS database there are only very few fields per record that

actually receive dbPuts (or get updated directly from within base). Only

for these fields is it necessary to provide storage for the time of the

last update. This storage will be allocated on demand; each record must

maintain a (typically very short) list of (field index, timestamp) pairs;

let us call it the 'field update list' or short 'update list'. When reading

the timestamp for a field, first search the update list and use the

contained stamp if one is found, otherwise use the TIME field of the

record.

How does that implement (b) ? If a field is never updated,
shouldn't that field then report the time when iocInit() was
executed?

-- T.

Memory management for the list nodes can and should use a freelist,

all nodes are of the same type (and thus size).

Each time the EPICS base updates a record field that can be read from the

outside it must also update the corresponding timestamp for the field in

this list, adding a new node if none is found. Each time the record's

process routine updates one of its fields it must /remove/ the field from

the list, so that the record's timestamp is used when the field's timestamp

is requested via dbGet. To avoid having to change existing record supports

this could be done by db_post_events, where we assume that record support

calls db_post_events whenever record or device support has changed a field

that can be read from the outside.

The only problem is that record support changes fields (and calls

db_post_events) not only in process but also in special. But special gets

called only directly from base, so base must set a flag in the record to

indicate to db_post_events that special processing is active (and not

regular processing), so that it can add timestamp to the update list.

And that's it, nothing overly complex, AFAICS.

Cheers
Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System