Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Mon, 2 Feb 2009 15:05:12 +0100

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. 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
-- 
"TDD replaces a type checker in Ruby in the same way that a
strong drink replaces sorrows."       (byorgey on #haskell)

Any text below this line has automatically been added by the
mail server and does not necessarily represent my personal opinion.
-------------------------------------------------------------------

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH   
Glienicker Straße 100, 14109 Berlin   
Vorsitzende des Aufsichtsrates: Dr. Beatrix Vierkorn-Rudolph   
Stellvertretende Vorsitzende: Dr. Jutta Koch-Unterseher   
Geschäftsführer: Prof. Dr. Anke Rita Pyzalla, Prof. Dr. Dr. h.c. Wolfgang Eberhardt, Dr. Ulrich Breuer   
Sitz der Gesellschaft: Berlin Handelsregister: AG Charlottenburg, 89 HRB 5583   

Information:   
Durch die Fusion mit dem ehemaligen Hahn-Meitner-Institut (HMI) ist   
BESSY nun Teil des neuen Helmholtz-Zentrum Berlin für Materialien   
und Energie (HZB).    

By the merger with the former Hahn-Meitner-Institut (HMI), BESSY   
became part of the new Helmholtz-Zentrum Berlin für Materialien und   
Energie (HZB).   

Disclaimer automatically attached by the E-Mail Security Appliance   
mail0.bessy.de 02/02/09 at Helmholtz-Zentrum Berlin GmbH. 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System