Re: wrong timestamps in monitors

[Till Straumann <strauman@slac.stanford.edu>]

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
>