Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Thu, 29 Jan 2009 13:04:09 -0600

Benjamin Franksen wrote:
> - If the field does not have the PP property, then the record is not 
> processed as a result of the put, and the CA event is posted with the old 
> timestamp.
>
> - If the field /does/ have the PP property, then the record gets processed 
> as a result of the put, which woudl update the record's timestamp, but 
> processing comes /after/ EPICS base posts the event, thus the event has the 
> wrong (old) timestamp.

To try and state the problem succinctly: you can only be sure that a timestamp 
reflects the time when the value was recorded if you're looking at a field 
which can only get updated as a result of record processing, i.e. one that is 
marked  by the RecRefManual with a Yes in the "Rec Proc Monitor" column and 
a "No" in the "Modify" column.  There are actually very few of those...

BTW, the VAL field is special; the runtime currently assumes that the record 
type will always post monitors on VAL when the record is processed, thus the 
dbPut() routine deliberately avoids posting monitors on VAL if it is marked 
PP=YES.  Your second paragraph above thus does not apply to VAL fields.  You 
can confirm that by monitoring the VAL field of a sequence (seq) record, the 
process routine of which only posts monitors on VAL when the alarm 
status/severity of the record changes — while monitoring it, you can change 
VAL as much as you like and the monitor won't update even though the record 
is processing (set TPRO to confirm that).

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.

> It should be clear that this means one should /not/ trust the history of 
> value changes as e.g. reported by the channel archiver (or simply the 
> output of camonitor) whenever the PV in question references a non-VAL 
> field. At least not w.r.t. the reported timestamps.

Thus I think the fundamental issue here is not really in the database at all; 
I'd argue instead that the Channel Archiver is misusing the timestamp it gets 
from CA.  It would *like* it to reflect the time when the data was recorded, 
but the IOC has never claimed that it provides that information.  One could 
make that assumption for some channels, but not for all.

I believe it is well-recognized that the status and severity of a PV reflect 
the state of the record containing that PV rather than the state of PV value 
itself.  If I'm looking at the DESC field of a record, I can still rely on 
the string returned even when the state I get with it is UDF/INVALID.  It is 
unfortunate that the similar disconnect may have been forgotten for 
timestamps.

> Is this going to be addressed any time soon?

I suggest that the place to fix that problem is in the Channel Archiver, not 
in the IOC.  The configuration file needs to be able to tell the Archiver for 
each PV whether to use the timestamp from CA or to record a local timestamp 
whenever it receives a monitor callback or polls for an update.

- Andrew
-- 
The best FOSS code is written to be read by other humans -- Harold Welte

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System