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.
- Replies:
- Re: wrong timestamps in monitors Till Straumann
- Re: wrong timestamps in monitors Andrew Johnson
- References:
- wrong timestamps in monitors Benjamin Franksen
- Re: wrong timestamps in monitors Andrew Johnson
- Navigate by Date:
- Prev:
boot vxworks from ppcbug in mv5100 zhuangjian
- Next:
Re: EDM text control for password entry Steve Kinder
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: wrong timestamps in monitors Mark Rivers
- Next:
Re: wrong timestamps in monitors Till Straumann
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|