DAQInterface verbosity levels should be revisited
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.
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
JCF: Issue #23364: below debug level 2, if all artdaq processes return Success, just summarize it in one sentence. Also, add benchmarking info
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
JCF: Issue #23364: revamp the subsystem and process info printout which appears at debug level 2 or higher at start of boot
JCF: Issue #23364: some tweaks to the output so the language is more precise/better formatted
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
JCF: Issue #23364: if not the last commit for this issue, then close to the last
JCF: Issue #23364: revert the demo config back to something that's artdaq v3_07_XX-compatible
#1 Updated by John Freeman about 1 year 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?
#3 Updated by Kurt Biery about 1 year 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.
#4 Updated by John Freeman about 1 year ago
- 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 year 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...