Advanced Memory Usage

Advanced Memory Usage

When advanced memory usage is set in the DAQInterface settings file, a few requirements are brought in. These include the following:

• max_fragment_size_bytes must not be set in the DAQInterface settings file, as setting this is logically exclusive of the behavior of advanced memory usage. It’s recommended that you comment it out (as opposed to deleting it), in case you wish to switch back to non-advanced memory usage.

• The FHiCL document for every BoardReader used in a run has to have the parameter max_fragment_size_bytes set. E.g., in a BoardReader’s ToySimulator FHiCL, you might see something like: nADCcounts: 5000 max_fragment_size_bytes: 10200

  where you want to ensure that max_fragment_size_bytes represents the largest fragment you can imagine your fragment generator producing. In the above example, the ToySimulator is configured to produce 5000 2-byte ADC counts per fragment; setting the max fragment size to 10200 bytes more than allows for the additional space required by the artdaq fragment header.

• The FHiCL document for every other type of artdaq process (i.e., the non-BoardReaders) must not contain a max_fragment_size_bytes variable. The reason is that this variable is ignored and highly misleading for non-BoardReader processes when advanced memory usage is in place.

As a practical matter, DAQInterface will both use the max_fragment_size_bytes setting when configuring the transfer plugins (i.e., the data transport code which conveys data between BoardReaders and EventBuilders), and when determining the max event size EventBuilders and downstream processes can handle (where this max event size is calculated to be the sum over every BoardReader’s max_fragment_size_bytes, with an overhead of 10% to account for art code which gets injected into the byte stream).