Project

General

Profile

Bug #23364

DAQInterface verbosity levels should be revisited

Added by John Freeman 4 months ago. Updated about 1 month ago.

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

100%

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

Description

The statements that DAQInterface prints are controlled by the "debug level" setting in the boot file; the higher the level, the more it prints. Statements have been added over the years but rarely removed or reworded. It may be helpful to users if some of the statements get revisited - e.g., removal of redundant information, or increasing the debug level required to print out statements which announce success in very-rarely-failing actions.

Associated revisions

Revision f21c554c (diff)
Added by John Freeman 3 months ago

JCF: Issue #23364: instead of announcing that stuff may be getting saved to the database if the database is in use, announce that stuff's definitely getting saved but only do so if the database is in use

Revision 53f2fbc0 (diff)
Added by John Freeman 3 months ago

JCF: Issue #23364: below debug level 2, if all artdaq processes return Success, just summarize it in one sentence. Also, add benchmarking info

Revision 8768138c (diff)
Added by John Freeman 3 months ago

JCF: Issue #23364: miscellaneous improvements to output

Revision a65c5400 (diff)
Added by John Freeman 3 months ago

JCF: Issue #23364: improve output when malformed FHiCL is read in and increase verbosity level required for printout of full set of artdaq process launch commands

Revision de4ae60a (diff)
Added by John Freeman 3 months ago

JCF: Issue #23364: at debug level 2, print out comprehensive log file info

Revision 0ccaeec4 (diff)
Added by John Freeman 2 months ago

JCF: Issue #23364: revamp the subsystem and process info printout which appears at debug level 2 or higher at start of boot

Revision f45973f6 (diff)
Added by John Freeman 2 months ago

JCF: Issue #23364: some tweaks to the output so the language is more precise/better formatted

Revision 2bdec663 (diff)
Added by John Freeman 2 months ago

JCF: Issue #23364: improvements to what appears at debug level 3

Revision be60a356 (diff)
Added by John Freeman 2 months ago

JCF: Issue #23364: increase the debug level for when artdaq processes just directly dump output to DAQInterface's stdout and make sure that at debug level 3 or higher the output of the test-sourcing of the DAQ setup script is shown

Revision f48d58db (diff)
Added by John Freeman 2 months ago

JCF: Issue #23364: if not the last commit for this issue, then close to the last

Revision 0a477d14 (diff)
Added by John Freeman 2 months ago

JCF: Issue #23364: final cleanup of output

Revision 5528afd9 (diff)
Added by John Freeman about 1 month ago

JCF: Issue #23364: add time info for process transitions

Revision 9139fafb (diff)
Added by John Freeman about 1 month ago

JCF: Issue #23364: revert the demo config back to something that's artdaq v3_07_XX-compatible

Revision 86f08519 (diff)
Added by John Freeman about 1 month ago

JCF: Issue #23364: fix bug where the shutdown transition times were calculated in reverse

History

#1 Updated by John Freeman 2 months ago

  • Status changed from New to Resolved

Resolved with commit 0a477d14dfe061b8ee667c5d4094e8e6a1174df6 on feature/23364_verbosity_output. Reviewing this issue will obviously be more subjective than most issues, but here are some things to look out for:

1) For a given verbosity level, does any info printed to screen look insufficiently important, so that it should be demoted to a higher verbosity level? Conversely, is there any info which is important enough that it should also appear at lower verbosity levels?

2) With timestamps, the benefit is you know when something got printed, the drawback is that it adds clutter to the screen and makes the message harder to read. Are there statements which should have timestamps removed or added?

3) For common failure modes - e.g., illegal FHiCL syntax in the configuration - is it clear what's going on? In general, does it seem like DAQInterface's output will minimize the number of emails we'll receive?

#2 Updated by John Freeman 2 months ago

One other point, concerning the rough meaning of the verbosity levels:

0 -- deprecated
1 -- standard
2 -- meant to help an experiment's users debug problems
3-5 -- meant for members of our group to debug problems
6+ -- same as level 5

#3 Updated by Kurt Biery about 2 months ago

I've run some tests with this version of DAQInterface, and it looks quite nice.

A few comments:
  • I merged the "develop" branch in artdaq-utilities-daqinterface into the "feature/23364_verbosity_output" branch, and I needed to resolve a conflict in daqinterface.py as part of that merge. John, please check that I didn't introduce a merge error by my choice.
  • I didn't see any difference between verbosity level 3 and level 9. Maybe there isn't supposed to be.
  • I wonder if it would be useful to have timestamps associated with the replies from the artdaq processes to transition requests. In normal running, it doesn't much matter, but if one of them were to take a long time, it might be useful to know exactly how long.

Thanks,
Kurt

#4 Updated by John Freeman about 1 month ago

Thanks for reviewing. To respond to your points:
  • Your conflict resolution edit was just fine, though I removed an unnecessary mkdir call which snuck in.
  • There are a couple of differences between levels 3, 4, and 5, but they're minor, and only appear in certain scenarios (msgviewer launch, pmt process management, etc.). I propose that anyone that's not me only focus on levels 1-3.
  • Great point about transition times. I've added info on this to DAQInterface's output; please take a look.

#5 Updated by Kurt Biery about 1 month ago

Ah, cool. I was thinking just simple timestamps for the transition request output, but the time deltas are a nice touch. It was a little odd seeing negative values (e.g. -0.1 seconds) for some of the terminate transition times. Not sure if that is expected or not...

#6 Updated by John Freeman about 1 month ago

The negative times were a screwup, since the delta for the shutdown transition was being calculated as (start time - end time), not the other way around. Fixed with commit 86f08519655224008012ad8eeda7984cff6c17c2.

#7 Updated by Kurt Biery about 1 month ago

  • Status changed from Resolved to Reviewed

With the latest code, the deltas for the Terminate transition look good.

Marking this Issue Reviewed.



Also available in: Atom PDF