search

DUNE-DAQ / readout

This package contains Upstream DAQ Readout specific software and utilities, appfwk DAQModules, CCM interface implementations, and software emulators.
2 stars 1 forks source link

Data timestamps should continue increasing after "stop" command #56

Open philiprodrigues opened 3 years ago

philiprodrigues commented 3 years ago

Currently, when two runs occur in the same process (that is, we have something like "init, conf, start, stop, start, ..."), the data timestamps in the second run are reset to the same values as they had in the first run. This appears to happen both with and without emulator_mode.

The problem here is for the interaction with TriggerDecisionEmulator: TDE would like to keep consuming TimeSync messages for the whole "conf -> scrap" period, in order to prevent TimeSync messages piling up and filling up queues. But if we do that, the TDE timestamp estimation logic gets confused by the timestamps resetting (there's some relevant discussion at https://github.com/DUNE-DAQ/trigemu/issues/22 )

bieryAtFnal commented 3 years ago

If/when the change described in this Issue gets implemented (timestamps can continue increasing between runs, even when reading data from a frames.bin file), I can imagine that it will be straightforward to set the offset of the timestamps in the first run to effectively "now" (according to wallclock time). So, I would like to make that request.

Stated another way... Currently, the timestamps that we get when we run a system with the FakeCardReader module with data from a frames.bin file that was taken in July of 2020 start at approximately 2020-07-19 13:05:02. It would be great if they started at approximately the current wallclock time when the user of the test system sent the "start" command to the system.

roland-sipos commented 3 years ago

I think this needs to be discussed on a call, rather than in comments. I don't necessarily agree with keeping the timestamp increment ongoing "out-of-run". We are data driven. The TS faking is purely for emulation. If there is nothing to fake (in stop, there is no data arriving to readout source queues), we probably should not introduce blanks.

philiprodrigues commented 3 years ago

Kurt pointed me to a related issue: the start command is sent to the apps/modules serially, rather than in parallel. With multiple readout apps each with many links, the time between starting each link can become large enough to result in empty fragments at run end (because each link starts at different wall-clock times, but they all start with the same timestamp, so they are out of sync). I think this is a point in favour of setting the first timestamp in the buffer to the current system time, converted to timestamp units. (I don't think it makes a difference to the discussion about what we do with timestamps between runs)