Project

General

Profile

Feature #20451

Clean up the specification of max fragment and event sizes

Added by Kurt Biery about 1 year ago. Updated 12 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
07/25/2018
Due date:
% Done:

100%

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

Description

At the moment, we have max_event_size_bytes(words) and max_fragment_size_bytes(words), as well as size parameters in the source and destination blocks in our configurations, the latter of which are book-kept by DAQInterface, and all of this is confusing and likely inconsistent.

An idea that John and I talked about is to move to a model in which BoardReader configurations can/should specify max_fragment_size_bytes, and everything else is derived. For example, the max_event_size_bytes in the EventBuilder would be the sum of the BR sizes for the BRs that are currently included in the partition.

DAQInterface would be the logical place to do this sort of bookkeeping.

We should think about whether configuration parameters like TCP send buffer sizes can be naturally handled in this model, or if we need special handling for them.

History

#1 Updated by John Freeman 12 months ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100

A more streamlined, logically consistent approach to setting buffer sizes is now available in DAQInterface v3_03_00 if a user sets advanced_memory_usage: true in the DAQInterface settings file. Details on this are described in Issue #20580 and Issue #20581.



Also available in: Atom PDF