Hi:
Are these 'scanned' channels?
What can happen is this:
Your PV never changes, it's timestamp is T0.
The archive engine scans the channel.
Every time, the sample engine gets the same value, so it doesn't write
anything to the archive.
But once upon a time there were users who then complained:
Why is there nothing in my archive?
How do I know if
a) The value really didn't change
b) The engine stopped functioning.
So after N repetitions of the same value, the engine _does_ write another
sample with the current host time stamp.
N = max repeat count
Read section 3.1.6 of the manual:
http://ics-web.sns.ornl.gov/kasemir/archiver/manual.pdf
If you now restart the engine, it'll first store the "real" sample with time
T0 in the new sub-archive, and then add those ARCH_REPEAT samples again.
Thanks,
-Kay
On 10/1/10 05:54 , "[email protected]"
<[email protected]> wrote:
> Hi
>
> Does anyone have experience with overlapping blocks appearing in the
> Rtree Channel Archiver?
>
> Our archive engine restarts each week. For a channel, sometimes the
> first sample in the new week's archive has the same timestamp and value
> as the first sample in the previous week's archive, after that the
> samples are correct. This is not related to the IOC timestamps as it
> happens across many channels. We do connect through the gateway but I'm
> not aware of a gateway bug that could cause this.
>
> Previous week SSSSSSSSSSS
> New week S____________SSSSSSSSS
>
> James
>
> [jr76@pc0053 archiver_indexer]$
> ~/archiver/trunk/bin/linux-x86/ArchiveDataTool -verbose \
> 3 /extra1/index/archiver1/raid1/PS/2010/06_09/index -blocks -channel
> LI-PS-VAULT-01:SRCH\
> COUNT
> RTree M for channel 'LI-PS-VAULT-01:SRCHCOUNT': 50
> Datablocks for channel 'LI-PS-VAULT-01:SRCHCOUNT':
> '20100609' @ 0xB4E6ED: Indexed range 06/08/2010 09:46:37.516254210 -
> 06/16/2010 07:15:30\
> .669380000
>
> 1 data blocks, 0 hidden blocks, 1 total
>
> [jr76@pc0053 archiver_indexer]$
> ~/archiver/trunk/bin/linux-x86/ArchiveDataTool -verbose \
> 3 /extra1/index/archiver1/raid1/PS/2010/06_16/index -blocks -channel
> LI-PS-VAULT-01:SRCH\
> COUNT
> RTree M for channel 'LI-PS-VAULT-01:SRCHCOUNT': 50
> Datablocks for channel 'LI-PS-VAULT-01:SRCHCOUNT':
> '20100616' @ 0xBC0B10: Indexed range 06/08/2010 09:46:37.516254210 -
> 06/17/2010 10:26:40\
> .334905070
>
> 1 data blocks, 0 hidden blocks, 1 total
>
>
> --
> This e-mail and any attachments may contain confidential, copyright and or
> privileged material, and are for the use of the intended addressee only. If
> you are not the intended addressee or an authorised recipient of the addressee
> please notify us of receipt by returning the e-mail and do not use, copy,
> retain, distribute or disclose the information in or attached to the e-mail.
> Any opinions expressed within this e-mail are those of the individual and not
> necessarily of Diamond Light Source Ltd.
> Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments
> are free from viruses and we cannot accept liability for any damage which you
> may sustain as a result of software viruses which may be transmitted in or
> with the message.
> Diamond Light Source Limited (company no. 4375679). Registered in England and
> Wales with its registered office at Diamond House, Harwell Science and
> Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
>
>
>
>
>
>
- References:
- Channel Archiver overlapping blocks james.rowland
- Navigate by Date:
- Prev:
RE: Cross compiling EPICS for cris v10 Florian Feldbauer
- Next:
RE: Cross compiling EPICS for cris v10 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: Channel Archiver overlapping blocks james.rowland
- Next:
MOXA ARM computer and streamDevice Martin Konrad
- 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
|