Project

General

Profile

Feature #22244

Add hybrid fragment handling for GPS

Added by William Badgett 8 months ago. Updated 26 days ago.

Status:
Reviewed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
03/29/2019
Due date:
% Done:

100%

Estimated time:
Experiment:
ICARUS
Co-Assignees:
Duration:

Description

The SBND and ICARUS GPS board reader provides a small status fragment every one second. When running in "on demand" "pull" mode, we need to have at least the latest fragment included in the event, even if the fragment was already included in a past event. At times when there is a lull in the trigger rate, there may be multiple status fragments available to include in the event. Any fragment older than ~ 2 minutes can be discarded.

History

#1 Updated by Eric Flumerfelt about 1 month ago

  • Status changed from New to Resolved

Implementation on artdaq:feature/22244_CFG_BufferModeKeepLatestParameter

#2 Updated by John Freeman 26 days ago

  • % Done changed from 0 to 100

After merging the develop branch into feature/22244_CFG_BufferModeKeepLatestParameter so that the head of the feature branch is 02a21c5056f591e3eebfc42681e5984586f93f63, I performed a few runs on mu2edaq01 with one toysimulator ("component01") pushing fragments at a rate varying by the run, and another toysimulator ("component1001"), running with "request_mode: Buffer", consistently creating a fragment (a regular fragment, not a container fragment) once per second. As always for my studies on the mu2edaq cluster, the run records are subdirectories of /home/jcfree/run_records. I've got TRACE level 9 switched on for component1001's stdout, so the logfiles indicate which fragments are being bundled into the container fragment.

Run 3024:
I have component01 push a fragment twice per second. "buffer_mode_keep_latest" isn't set in component1001, meaning it defaults to false. If I execute

grep Apply /home/jcfree/daqlogs/component1001-mu2edaq01-11100/component1001-mu2edaq01-11100-20191025133249-12060.log

I can see that only container fragments with even-numbered sequence IDs get a fragment bundled into them. As expected.

Run 3025:
Same as run 3024 except that I set "buffer_mode_keep_latest: true" in component1001's FHiCL. If I execute

grep Apply /home/jcfree/daqlogs/component1001-mu2edaq01-11100/component1001-mu2edaq01-11100-20191025135257-20587.log

I now see that every container fragment gets a fragment bundled into it, except that each fragment gets bundled twice - which is what we'd expect, given that now component1001 "sits" on the fragment so it can bundle it into a container fragment again if there are no new fragments.

Run 3026:
Again we have "buffer_mode_keep_latest: true" in component1001's FHiCL, but this time component01 pushes a fragment only once every five seconds (i.e., component1001 generates five fragments in the time it takes component01 to push a fragment). If I execute

grep Apply /home/jcfree/daqlogs/component1001-mu2edaq01-11100/component1001-mu2edaq01-11100-20191025135832-49988.log

I now see each container fragment bundling five unique fragments- the expected result, since fragments don't need to be re-bundled.

Two caveats - I leave it up to Eric to decide whether or not they're serious enough to warrant more work, or whether we can consider this issue reviewed:

  • In all runs, for component1001, the container fragment with sequence ID 1 didn't have any fragments bundled into it
  • From looking at the code, there doesn't appear to be a mechanism to throw away fragments after 2 minutes as was suggested by Bill in the filing of this issue several months ago

#3 Updated by Eric Flumerfelt 26 days ago

I think the first item is okay, as Single mode works in the same way if it doesn't have any data to report.
The second item can be achieved using data_buffer_depth_fragments: 120 assuming that the Fragments come in at 1 Hz.

#4 Updated by John Freeman 26 days ago

  • Status changed from Resolved to Reviewed


Also available in: Atom PDF