Project

General

Profile

Bug #24262

DataLogger stop transitions take a **long** time in v3_08_00

Added by Eric Flumerfelt 5 months ago. Updated 22 days ago.

Status:
Closed
Priority:
Normal
Category:
-
Target version:
Start date:
04/02/2020
Due date:
% Done:

0%

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

Description

While testing across multiple nodes on the mu2edaq cluster, I have noticed that the DataLogger process can take an extremely long time (~530 seconds) to successfully stop. This may be related to #24242, but nevertheless should be investigated.


Related issues

Related to artdaq - Bug #24242: Dispatcher responds "busy" in subrun_exampleNew03/27/2020

History

#1 Updated by Eric Flumerfelt 5 months ago

  • Related to Bug #24242: Dispatcher responds "busy" in subrun_example added

#2 Updated by Eric Flumerfelt 4 months ago

  • Assignee set to Eric Flumerfelt
  • Status changed from New to Resolved

I've made several changes in artdaq:bugfix/24262_ArtdaqSharedMemoryService_StopConditions and artdaq-core:bugfix/24262_SharedMemoryEventReceiver_LimitExponentialBackoff, which seem to mitigate this issue on mu2edaq{12,11,14} using the mediumsystem_with_routing_master configuration for 5 one-minute runs.

#3 Updated by Eric Flumerfelt 4 months ago

There are two major changes made in the artdaq branch: EndOfData Fragments are passed into ArtdaqInputHelper, which uses them to determine if the run has ended before an init fragment was received, and TCPSocket_transfer changes to improve the reliability when TCP sockets are disconnected and reconnected.

#4 Updated by Eric Flumerfelt 22 days ago

  • Target version set to artdaq v3_09_00
  • Status changed from Resolved to Closed


Also available in: Atom PDF