Project

General

Profile

Feature #23362

Report inter-process communication network interfaces

Added by Kurt Biery 2 months ago. Updated 24 days ago.

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

0%

Estimated time:
Experiment:
-
Duration:

Description

In debugging a recent multicast problem at protoDUNE, and in debugging the changes that we have made to the configuration of multicast network interfaces in artdaq and DAQInterface, it would have been helpful to be able to easily see which network interfaces were being used by the underlying artdaq code in various scenarios.

This Issue requests that such reporting be added to the artdaq code. Ideally, this reporting would be at the TLVL_INFO level so that it can be found in the artdaq process log files, as well as in the TRACE buffer.

Associated revisions

Revision a614a967 (diff)
Added by Kurt Biery 2 months ago

Added TRACEs of the network interfaces that are used in inter-process communications like table updates, data requests, and token reporting. (Issue #23362)

Revision d56e7ae1 (diff)
Added by Kurt Biery 2 months ago

Switched from using ResolveHost to GetInterfaceForNetwork in RoutingMasterCore when processing the multicast_out_hostname_ ( Issue #23362 )

History

#1 Updated by Kurt Biery 2 months ago

For the initial development of these changes, I'm going to use an artdaq branch based on the v3_06_01 tag and an artdaq-demo area based on artdaq v3_06_01.

I'll use a branch name of feature/23362_ReportNetworkInterface.

#2 Updated by Kurt Biery 2 months ago

For better or worse, there have been two substantive changes that have come up as part of making these changes and testing them:

There was an empty line in RoutingMasterCore (https://cdcvs.fnal.gov/redmine/projects/artdaq/repository/revisions/develop/entry/artdaq/Application/RoutingMasterCore.cc#L367) that seemed to be missing an "exit(1)", so I added that. We should talk about whether that is the right option.

It is helpful to have the ResolveHost call in RoutingMasterCore actually be a call to GetInterfaceForNetwork so that we can use subnet addresses for RoutingMaster.fcl/routing_master_hostname.

#3 Updated by Kurt Biery 2 months ago

  • Status changed from Assigned to Resolved

Marking this Resolved.

#4 Updated by Eric Flumerfelt 2 months ago

  • Co-Assignees Eric Flumerfelt added

Code review & testing complete. I found a minor issue with RequestSender when 0.0.0.0 is passed as the multicast_out_address. When calling gethostname, it did not actually resize the string properly, leading to everything past the first 7 characters of the hostname to be truncated. Once this change has been independently verified, this issue can be considered reviewed.

#5 Updated by Kurt Biery 2 months ago

  • Status changed from Resolved to Reviewed
  • Co-Assignees Kurt Biery added

I have verified the fix to the gethostname call in RequestSender by running an artdaq-demo system with, and without, the fix on mu2edaq01.

I'm marking this Issue Reviewed, and I will merge the branch into develop. (and update the 'artdaq branches' page)

#6 Updated by Eric Flumerfelt 24 days ago

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


Also available in: Atom PDF