1. 35t Readout Software John Freeman Dune Collaboration Meeting September 3, 2015

2. RunControl, DAQInterface, Configuration Manager and TDUControl (not shown, sends sync pulse at run start) Every run consists of a configuration and a set of components For a given configuration, 1-1 correspondence between a component, an artdaq boardreader process, and a FHiCL document initializing the process

3. Top N things DAQ operators should know Running check_daq_application.sh will tell you which of the four applications are running, as well as the most recently written logfile If you plan on using these applications, make a note of it in the e- log The two most important sites on the internet are: E-log: http://dbweb3.fnal.gov:8080/ECL/lbne_35t/E/indexhttp://dbweb3.fnal.gov:8080/ECL/lbne_35t/E/index Wiki describing how to run the DAQ: https://cdcvs.fnal.gov/redmine/projects/lbne- daq/wiki/Running_DAQ_Interface Months of work have gone in to making this wiki as comprehensive as possible, while still retaining readability…

4. More?

5. MsgViewer Hot off the press: a program called MsgViewer now pops up whenever DAQInterface is launched Any messages sent via the lbne-artdaq’s DAQLogger module will appear in the viewer E.g., DAQLogger::LogError() << “Message”; will: Appear as “Message” in red in the viewer Send an alert up to run control containing “Message” Throw an exception, also containing “Message” For more info, see https://cdcvs.fnal.gov/redmine/projects/lbne- artdaq/wiki/Info_on_Using_DAQLoggerhttps://cdcvs.fnal.gov/redmine/projects/lbne- artdaq/wiki/Info_on_Using_DAQLogger The lbne-artdaq codebase should begin using DAQLogger, rather than cout/cerr or various group-specific logging mechanisms.

6. More?

7. The following four slides were provided to me from Erik Blaufuss, concerning upcoming plans for RunControl…

8. Run control status and plans

9. Current status Current run control functionality Control DAQ: configure, start and stop runs Select desired configuration from list Select desired components (SSPs. RCEs) from list Select run type (Physics/Test/Commissioning) Save a run summary DB record for each run includes: Start, stop times (UTC) selected configuration name selected component list run type DB records are (will be?) mirrored to public servers Accepts monitoring value reports from anyone (JSON over 0MQ)

10. Planned work Slow control values from HV/Cryo systems Alan H reported CSV files to shared directory Parsed, displayed and reported to Conditions DB Basic Web display Basic rate plots, Cryo/HV values plotted for recent time period Current run status information Help with documentation Suggestions welcome, now or as we start up….

11. Current UI plans

12. Recent Networking Issues (I) Several weeks ago now, the dumb switch the SSPs had been connected to was swapped out for a Cisco switch The connection to the SSPs stopped working After plenty of troubleshooting, the connection started working again when the switch was “dumbed down” – i.e., stopped sending spanning tree and CDP (Cisco Discovery Protocol) packets

13. Recent Networking Issues (II) As an outgrowth of this work, we studied the rate at which data could flow through the SSPs Each SSP’s corresponding fragment generator sends 200 fragments per second, but the size of the fragment is linearly related to the hardware trigger frequency Assuming backpressure isn’t occurring, which is indicated by orange (and then red) FIFO lights On the next slides, assume that the rates achieved were done without FIFOs complaining

14. Network dataflow study Max dataflow achieved @ trigger period 1.7 ms (~590 Hz): 86 MB/s into lbnedaq1 115 MB/s into lbnedaq2

15. Some interesting results Running no ssp fragment generators on lbnedaq1 and N ssp fragment generators on lbnedaq2, data rate into lbnedaq2 achieved was N = 1 -> 43 MB/s N = 2 -> 86 MB/s N = 3 -> 98 MB/s N = 4 -> 116 MB/s N = 5 -> 116 MB/s Of course, true rates remain to be seen when we have everything at PC4 and 16 RCEs + the penn trigger board running in parallel with the SSPs There are several other lbnedaq nodes, so it will be worth studying the optimal way to allot the fragment generators on these nodes as well as potentially useful hardware upgrades (10 gigabit cables, more NICs, etc.)

16. A few “best practices” If you’re adding to lbne-artdaq, before you commit your changes to its central develop branch, make sure that lbne-artdaq still compiles and runs when you merge in your changes Corollary: since versions of packages lbne-artdaq depends on can and do get bumped up, it’s worth periodically checking out a clean copy of lbne- artdaq via “quick-start.sh” See https://cdcvs.fnal.gov/redmine/projects/lbne- artdaq/wiki/Best_practices_for_code_development for morehttps://cdcvs.fnal.gov/redmine/projects/lbne- artdaq/wiki/Best_practices_for_code_development If you update the configuration directory, make sure you git commit the configuration, otherwise DAQInterface will refuse to run Before contacting experts concerning the DAQ, your question(s) may already be answered in the https://cdcvs.fnal.gov/redmine/projects/lbne- daq/wiki/Running_DAQ_Interface

17. Conclusions The DAQ applications admittedly have a 1980s feel to them, but have been under development for over a year and are quite robust and as simple to use as flexibility allows Though if you have any ideas for improvements, please contact me at jcfree@fnal.govjcfree@fnal.gov They’re also well documented MsgViewer has been a useful start, and hopefully over the coming weeks and months determining what the DAQ is doing in real time will become easier than simply trolling the logfile via “tail –f” Thanks to everyone who’s helped out!