Andrew Johnson wrote:
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
I see that the current implementation is that a monitor
provides the timestamp when the record was last processed.
But if you look, for example, with "camonitor" on a PV,
you would expect the timestamp the program shows in the same line
has something to do with the time the PV changed.
Here I have an example:
U125ID2R:BaseParGapsel.B 2009-01-29 09:07:10.455966 150
U125ID2R:BaseParGapsel.B 2009-01-29 09:07:10.455966 1000
U125ID2R:BaseParGapsel.B 2009-01-29 13:26:11.956084 185
at 13:26 I wrote "1000" to the PV. The record the processed and
changed it's field B to 185. If I look at the output
I would assume that the value changed at 09:07. This is wrong
by about 4 and a half hours. I do not know how long in the past I stared
at print-outs from camonitor or the archiver trying to debug my
database and wondering what happened just because the timestamps
do not always show the time the PV did change.
The conclusion is that timestamps for non-value fields only show
that the value changed some time after the given timestamp, it may
be seconds, months or years later. I would expect that this
non intuitive behavior is at least documented somewhere. It obviously
violates the principle of the least surprise.
-- Goetz
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 01/30/09 at Helmholtz-Zentrum Berlin GmbH.
- Replies:
- RE: wrong timestamps in monitors Mark Rivers
- References:
- wrong timestamps in monitors Benjamin Franksen
- Re: wrong timestamps in monitors Andrew Johnson
- Navigate by Date:
- Prev:
Re: wrong timestamps in monitors Dirk Zimoch
- Next:
RE: wrong timestamps in monitors Mark Rivers
- 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 Dalesio, Leo
- Next:
RE: wrong timestamps in monitors Mark Rivers
- 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
|