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.
