Project

General

Profile

Bug #25056

Fragment Buffer defaults to uint32_t(-1) for Stale Fragment timeout

Added by Eric Flumerfelt about 2 months ago. Updated about 1 month ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
10/08/2020
Due date:
% Done:

0%

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

Description

In ICARUS, they were assuming that if the stale_fragment_timeout parameter was not set, then Fragments would not time out. However, artdaq had the default set to 0xFFFFFFFF, which since ICARUS's clock is in nanoseconds, only results in a timeout of 2.7 seconds.

Also, the parameter is misnamed "stale_request_timeout", when it really should be "stale_fragment_timeout".

circular_buffer_mode_example.taz (3.37 KB) circular_buffer_mode_example.taz Gennadiy Lukhanin, 10/16/2020 02:13 AM

History

#1 Updated by Eric Flumerfelt about 2 months ago

  • Status changed from New to Resolved

Implemented on artdaq:bugfix/25056_FragmentBuffer_StaleFragmentTimeout

#2 Updated by Eric Flumerfelt about 2 months ago

  • Experiment ICARUS added
  • Experiment deleted (-)

#3 Updated by Gennadiy Lukhanin about 2 months ago

  • Reviewed the source code.
  • Ran a modified circular_buffer_mode_example config in the "window" pull mode with compoment{01,02}.
  • Confirmed that the "Determining if Fragments can be dropped from data buffer" message is not printed unless the stale_fragment_timeout setting is added to component02 and has a non zero value.

#4 Updated by Eric Flumerfelt about 1 month ago

  • Target version set to artdaq v3_09_02
  • Status changed from Reviewed to Closed

Also available in: Atom PDF