Changes to avoid warning messages when tardy TPs arrive at the TPStreamWriter #358
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 2 commits
July 2, 2024 09:56
…ce to support our desire to not complain too loudly when late-arriving TPs can't be added to existing TimeSlices in the TPStreamWriter.
…mWriter and to better track such a condition with additional metrics.
|
Questions to be discussed in meetings on Wednesday...
|
|
Results from a 30-second emulated-data test run with 2 ReadoutApps, each with 3 links. In this run, the TPs from the two RUs were close in time (so no warnings should have been produced). The flag for allowing the warning messages was set to false. |
|
Results from a 30-second emulated-data test run with 2 ReadoutApps, each with 3 links. In this run, the TPs from the two RUs were close in time (so no warnings should have been produced). The flag for allowing the warning messages was set to true. (but, no warning messages were produced, as expected) |
|
Results from a 30-second emulated-data test run with 2 ReadoutApps, each with 3 links. In this run, the TPs from the two RUs had a significant amount of time between them (~2.5 seconds), so TPs should have been dropped. The flag for allowing the warning messages was set to false, so no warning message should have been produced, but the loss of TPs should be visible in the metrics. To avoid warning messages about TPs not being available in the RU latency buffers, the data request timeout was increased in this run, and extra time was allowed at the start and end of the run without triggers. |
|
Results from a 30-second emulated-data test run with 2 ReadoutApps, each with 3 links. In this run, the TPs from the two RUs had a significant amount of time between them (~2.5 seconds), so TPs should have been dropped. The flag for allowing the warning messages was set to true, so warning message should have been produced, and the loss of TPs should be visible in the metrics. |
|
added 5 commits
July 3, 2024 11:11
… the TimeSlice class where it is used in the TPStreamWriter code.
…discussion at 03-July Core SW meeting
…tpsw_ignore_late_tps
|
Here are samples of the latest metrics (shown in collated form from the disk-output opmon mode): and here is a sample warning message: |
wesketchum
approved these changes
Jul 6, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR depends on ones in daqdataformats and hdf5libs.
These changes include a flag to control whether warning messages are produced when tardy TPs arrive at the TPStreamWriter. They also include additional metrics to provide insight into lost TPs when the warning messages are disabled.