Time stamp and synchronisation of QC objects

Dear all,

we are wondering about the time stamp of QC objects and how/if they will be synchronised. I think, this was already discussed at some point, but I couldn’t find anything related, so if there is already some ticket open (ALICE Talk, JIRA, …), please just point me to it.

Here our thoughts and questions:

  • We think, the time stamp of a QC object has to be linked to the data taking period, not to the run time of the QC task. Which time is currently used? E.g. looking at the CCDB one gets 3 times for “Valid from”, “Created at” and “Last modified”, which are in general not identical. And if we understand correctly, all these times are related to the running of the QC task, not to the data taking.
  • In any case, we think that the time stamp should be identical for all QC tasks, as the underlying data cannot be correlated otherwise.
  • Is it foreseen to have identical cycles for all QC tasks, meaning that the QC objects of all tasks span identical data taking periods? In principle, for one detector all tasks can be set up within one single json configuration, but still we are not sure, if they are started at the exact identical time. And in general identical times would be needed for all detectors, as e.g. for the TPC we will also need info from ITS, TRD and TOF.
  • Finally, also to create the data tags, the time intervals need to be identical.

We would be glad about any insight or link to an existing discussion.


the topic was discussed during a WP7 meeting and I even remember you participating :wink:

Now, as far as I remember:

  • “Created at” == “Valid from” == time of publication
  • “Last modified” - I don’t know, probably as above

What I think we will do:

  • “Created at” - stay as before
  • “Valid from” - first TF ID of a run or first TF ID in an object.
  • “Valid until” - last TF ID of a run or “now”
  • QCG will display the latest valid object by default and will allow to select runs/periods/etc.

I agree.

Identical cycles - no, they will vary depending on the resource usage of a QC Task and how often an update is needed. Also, generating a big spike of data transfer once per minute is a bad idea.
Span identical data taking periods - yes, or at least very close.


In general, this is on our todo list and I hope we can implement the changes soon, because it is indeed becoming more and more important now. (though I am leaving for holidays tomorrow).

1 Like

Hi Piotr,

thanks a lot for your replies and esp. the link. This is, what I had somewhere in my mind and couldn’t find it anymore and yes, indeed I was participating in that meeting. :slight_smile:

I am looking forward to the implementation, but now first of all have nice vacations!