Delayed postprocessing timeout logic#104
Conversation
alessandrothea
left a comment
alessandrothea
left a comment
There was a problem hiding this comment.
Looks good to me so far!
alessandrothea
left a comment
alessandrothea
left a comment
There was a problem hiding this comment.
Looks very nice. Just one comment about the postprocessing timeout logic.
|
|
||
| auto model = | ||
| unittest::MockDataHandlingModel<ReadoutType, | ||
| DefaultRequestHandlerModel<ReadoutType, SkipListLatencyBufferModel<ReadoutType>>, |
There was a problem hiding this comment.
Do we want the same test with a queue?
There was a problem hiding this comment.
No... delayed postprocessing only makes sense for skip list.
| return 0; | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
Ok, this is just an optimization, but maybe still worth considering:
After a few timeouts, end_win_ts will settle on newest_ts+1, so maybe one could check here if
end_win_ts >= m_unprocessed_element.get_timestamp() and if so, stop the processing here.
@denizergonul let me know what you think.
There was a problem hiding this comment.
I suggest m_processed_up_to.get_timestamp() >= newest_ts + 1
There was a problem hiding this comment.
(so we don't even calculate end_win_ts )
Renamed m_unprocessed_element Optimization in timeout logic
|
What's your final opinion on |
4 participants
DataHandlingModelthat will be overriden byTriggerDataHandlingModel. The function is called by postprocess scheduler.DUNE-DAQ/trigger#416