Project

General

Profile

Bug #23431

Possible issue with private-network bookkeeping (DAQInterface) on the protoDUNE DAQ cluster

Added by Kurt Biery 26 days ago. Updated 21 days ago.

Status:
Reviewed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
10/16/2019
Due date:
% Done:

100%

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

Description

When trying to take data at protoDUNE with dune-artdaq software based on e17:s83 and the latest DAQInterface v3_00_07e, I found that data requests were not successfully being transmitted between EventBuilders and BoardReaders. Below, I've included the results of a "grep" for "multicast" in the run_records directory for the run in question.

I wonder if the problem is related to the fact that the BR computers only see the 10.73.136.0 network, while the EB computers see both 10.73.136.0 and 10.73.138.0.

[np04daq@np04-srv-001 9868]$ date
Wed Oct 16 22:56:45 CEST 2019
[np04daq@np04-srv-001 9868]$ pwd
/nfs/sw/artdaq/run_records/9868
[np04daq@np04-srv-001 9868]$ grep multicast *
cob3_rce05.fcl: multicast_interface_ip: "0.0.0.0"
cob3_rce05.fcl: table_update_multicast_interface: "10.73.136.0"
cob3_rce06.fcl: multicast_interface_ip: "0.0.0.0"
cob3_rce06.fcl: table_update_multicast_interface: "10.73.136.0"
cob3_rce07.fcl: multicast_interface_ip: "0.0.0.0"
cob3_rce07.fcl: table_update_multicast_interface: "10.73.136.0"
cob3_rce08.fcl: multicast_interface_ip: "0.0.0.0"
cob3_rce08.fcl: table_update_multicast_interface: "10.73.136.0"
cob4_rce01.fcl: multicast_interface_ip: "0.0.0.0"
cob4_rce01.fcl: table_update_multicast_interface: "10.73.136.0"
cob4_rce02.fcl: multicast_interface_ip: "0.0.0.0"
cob4_rce02.fcl: table_update_multicast_interface: "10.73.136.0"
cob4_rce03.fcl: multicast_interface_ip: "0.0.0.0"
cob4_rce03.fcl: table_update_multicast_interface: "10.73.136.0"
cob4_rce04.fcl: multicast_interface_ip: "0.0.0.0"
cob4_rce04.fcl: table_update_multicast_interface: "10.73.136.0"
cob4_rce05.fcl: multicast_interface_ip: "0.0.0.0"
cob4_rce05.fcl: table_update_multicast_interface: "10.73.136.0"
cob4_rce06.fcl: multicast_interface_ip: "0.0.0.0"
cob4_rce06.fcl: table_update_multicast_interface: "10.73.136.0"
EventBuilder11.fcl: multicast_interface_ip: "10.73.138.0"
EventBuilder3.fcl: multicast_interface_ip: "10.73.138.0"
timing_3.fcl: multicast_interface_ip: "0.0.0.0"
timing_3.fcl: table_update_multicast_interface: "10.73.136.0"

Associated revisions

Revision 3b3ddf39 (diff)
Added by John Freeman 24 days ago

JCF: Issue #23431: when checking for a boardreader's request mode, don't assume the value is enclosed in quotes

History

#1 Updated by John Freeman 24 days ago

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

The issue is resolved via the one and only commit on bugfix/23431_fix_private_network_bookkeeping, 3b3ddf39cb9e2275ed83783c04b3f30bc020933e. Basically, there was a line in bookkeeping intended to determine whether boardreaders were receiving requests or not:

res = re.search(r"\n\s*request_mode\s*:\s*\"%s\"" % (token), procinfo.fhicl_used)

which was missing the case where the request mode value wasn't surrounded with quotes (e.g., request_mode: window instead of request_mode: "window"). So the new line is:
res = re.search(r"\n\s*request_mode\s*:\s*\"?%s\"?" % (token), procinfo.fhicl_used)

i.e., the added question marks make the quotes optional.

On the ProtoDUNE cluster, the repo /nfs/sw/.artdaq-utilities-daqinterface currently is at the aforementioned commit. For testing, to use it instead of a tagged DAQInterface, in your favorite /nfs/sw/artdaq/DAQInterface/source_me[0-6] file just change

setup artdaq_daqinterface v3_00_07e
#. /nfs/sw/artdaq/DAQInterface2/mock_ups_setup.sh

to
#setup artdaq_daqinterface v3_00_07e
. /nfs/sw/artdaq/DAQInterface2/mock_ups_setup.sh

#2 Updated by John Freeman 21 days ago

  • Status changed from Resolved to Reviewed

Kurt's tested this bugfix branch successfully on the ProtoDUNE cluster, so I'm marking the issue as Reviewed.



Also available in: Atom PDF