Re: PVA custom structs

[Timo Korhonen via Tech-talk <tech-talk at aps.anl.gov>]

My favourite argumentation 😉

 

I am not sure about the archiver providing its own timestamps. This could lead to situations that misconfigured timing on the IOC side goes unnoticed because it looks fine. If no data is archived, it is straightforward to notice. If one is relying on precise timestamps (like we do in many cases) this could lead to the archived data being junk.

I am talking from the “millions of PVs” viewpoint. There could be cases for smaller installations where this might be helpful, but even there I would first try to make timestamp work properly on the IOC side.

 

Then the alarm status. The archived data comes practically always from IOCs(*). As a user, one of the most important things I want to know is if the data is valid, thus I look at the alarm status and if it is “invalid” then the data cannot be trusted. I cannot imagine cases where this would not be interesting. If there is one, I am happy to hear.

 

Timo

 

(*)I will not go into python “IOC”s, or rather PVA servers where one can only hope that alarm handling has been given attention.

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Tech-talk <tech-talk at aps.anl.gov>
Reply to: Ralph Lange <ralph.lange at gmx.de>
Date: Wednesday, 13 May 2026 at 08:37
To: Tech-talk <tech-talk at aps.anl.gov>
Subject: Re: PVA custom structs

 

On Tue, 12 May 2026 at 18:09, Heinz Junkes via Tech-talk <tech-talk at aps.anl.gov> wrote:

It's working now. I still had to delete all the old archiving requests.

 

Excellent!

 

@Sky, @Murali: Is it true that the alarm metadata is required for archiving?

If so, it should IMHO be an issue ticket. It's obvious that timestamps are required, but status/severity? Not sure.

 

(TBH, even for timestamps the archiver could fall back to its own system time. Arguable, but better than not archiving at all.)

 

Cheers,
~Ralph