Speakers:
Eric Flumerfelt
(Fermilab),
John Freeman,
Kurt Biery
(Fermilab),
Others,
Roland Sipos
(CERN)
From Kurt:
- Some notes and questions about Eric's addition of Fragment error bit checking functionality to integrationtests...
- the central PR is here
- recall that there are three types of fragment errors defined so far (here):
- kDataNotFound
- set in the FragmentHeader in datahandlinglibs::EmptyFragmentRequestHandlerModel and datahandlinglibs::DefaultRequestHandlerModel
- kIncomplete
- set in the FragmentHeader in datahandlinglibs::DefaultRequestHandlerModel
- kInvalidWindow (does not seem to be used anywhere yet)
- the new error-bit-checking functionality is great! However...
- all TriggerCandidate fragments have the kIncomplete bit set
- I believe that this is because we have deliberately set the request_timeout for these fragments to zero in order to get timely responses to DataRequests. The DefaultRequestHandlerModel obeys this directive, but it marks the fragment with the kIncomplete bit because there isn't data in the latency buffer later than the readout window.
- empty TriggerActivity fragments in kRandom triggers have the kDataNotFound bit set
- I imagine that we can work around this
- non-empty TriggerActivity fragments in kPrescale (TPG-based) triggers sometimes, but not always, have the kIncomplete bit set
- likely the same issue as TC fragments...
- similar issues are seen with TriggerPrimitive fragments
- My question is whether we really want trigger-related fragments to have the kIcomplete bit set, even though they have fully valid information.
- And, if we don't want that, how should we change the code to accomplish that.
- A possibly dumb question is whether we want empty fragments to have the kDataNotFound bit set. I presume yes.
- During the discussion of this topic at the meeting, Wes suggested that maybe renaming the kIncomplete bit would be a good way forward. This was received well by the group.
- Action items: Come up with a better name for kIncomplete. (Maybe kDidNotWaitForWindowClosure) Rename the FragmentHeader Error bits as Status flags/bits. And of course, apply these changes to the initial regression test changes that Eric made.
- This may necessitate a change of FragmentHeader version...
- We also talked a bit about how users can/should configure the DataRequest handling in Trigger and other non-TPC data handlers so that they return whatever data is in the latency buffer without waiting a long time for the data to be received after the readout window. Wes suggested a DataRequest timeout on the order of the readout window width. Action item: consider the same sort of thing in regression tests.
Eric:
- DFO Protocol changes, documentation here. Action items from the discussion:
- Add create_config_plot diagram of new layout (Kurt)
- Add Integration test showing DFO hand-off (Alessandro, Wes)
- Add documentation explicitly describing hand-off (Alessandro)
- Add documentation on necessary configuration changes (Marco)
- Appfwk ConfigurationManager/ModuleConfiguration change
- ModuleConfiguration functionality merged into ConfigurationManager
- Part of DAQModule API, so all DAQModules have to change `std::shared_ptr<ModuleConfiguration>` to `std::shared_ptr<ConfigurationManager>`
- Utilities Changes
- ReusableThread defined in both datahandlinglibs and utilities
- Goal was to move to utilities as it is not datahandling-specific
- [Kurt] These changes were given the go-ahead at the meeting.
- Remove Resolver::get_service_addresses (unused)
- Changes to TimestampEstimatorBase
- Potential race condition in while loops 39
- Implement exponential back-off in wait loop 41