search

DUNE-DAQ / dtpctrllibs

DUNE Trigger Primitives control modules
0 stars 0 forks source link

Implement monitoring in DTPController #6

Open jimbrooke opened 2 years ago

jimbrooke commented 2 years ago

Implement a monitoring thread in DTPController which will poll firmware and store state for collection by OpMon. In particular, access the MonProbe firmware node information.

This depends on https://github.com/DUNE-DAQ/dtpcontrols/issues/20

jimbrooke commented 2 years ago

Wait for resolution to https://github.com/DUNE-DAQ/daq-deliverables/issues/6 before fixing this issue

jimbrooke commented 2 years ago

@joealsubash asked for more info on this task. Here is (I think) a robust solution which relies on separate threads to fill and collect the monitoring info. Check that @alessandrothea agrees with this solution before proceeding. You can also ask @strilov for advice and examples from the timing sys.

  1. Add private members to DTPController to store the monitoring info, using std::atomic. (eg. vector of vector of MonProbeNodeInfo - but reimplemented using std::atomic_uint. Alternatively, update MonProbeNodeInfo to use atomic ?)
  2. Add a method to DTPController which calls get_info() on all available MonProbeNodes, and stores the results in the private members above.
  3. Add a dunedaq::utilities::WorkerThread to DTPController, which should periodically call the method above on some configurable interval (see https://dune-daq-sw.readthedocs.io/en/latest/packages/utilities/WorkerThread-Usage-Notes/ )
  4. Complete the dtpcontrollerinfo.jsonnet schema, such that it can store the info from all MonProbeNodes.
  5. Complete DTPController::get_info(), which should create a dtpcontrollerinfo info object, set its contents by copying from DTPController private members, and publish by calling ci.add() (see https://dune-daq-sw.readthedocs.io/en/latest/packages/opmonlib/Instructions-for-DAQ-module-users/#filling-and-collecting-structures )
alessandrothea commented 2 years ago

The suggestion is technically sound. What I am not sure about is sending modprobe data to monitoring. This is low-level debug information which is unlikely to be useful in its current form. I would from something at higher level.