Add hybrid fragment handling for GPS
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.
#2 Updated by John Freeman over 1 year 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.
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.
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.
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