1. General status updates/Schedule
2. Timing distribution updates (Rick has some slides)

Rick -- working on CFO and DTC firmware to check timing interfaces. Timing distribution board v2 with John is ready to be reviewed. Let’s review it next week.

Greg -- will send some thoughts to Rick on his slides (especially regarding CRV).

3. online Trigger Processing (including through DTC) progress/plans (highest priority)

Tomo -- Using time module were at 5.3ms and then down to 4.5ms on TDAQ node. Conversion to data products is 1.7ms. Has a profiler working better. Running multiple events and multiple cores is not completely working yet, need artdaq update.

Eric -- artdaq can’t see what art thread is doing. So hard to have artdaq timing.

Can we measure events/second at the FPGA tracking how many packets are readout? Rick will look into this

4. Status of tests with detector subsystems
Eric -- and Rick worked with Sten to move a TDAQ node to Argonne. Slow controls switches have been installed in DAQ room.

5. Rack protection & slow controls progress/plans

6. 1:30p Runs and Subruns
Rob -- two main topics:

Assumption is starting a next run is expensive.

Event IDs
40x20 event builders = 800 events processing in parallel

48-bit event window tag, is how events are built.
DAQ event has ~2500 event windows

Proposal low 32-bits of event window tag as event number for art.

SubRun to File relationship
Assumption that starting new sub run is inexpensive.

32-bit rollover would trigger a new subrun?

Offline would like runs to begin with 32-bit event number starts at 1.

Do we want event number to reset at subrun boundaries?

Runs would be something like 2 hours for 32-bit at 1695ns.
Subruns are 10-12 seconds for 2GB.

Perhaps, hardware does know run number, and 48bit event window tag = there will be a jump when new subrun starts.. E.g 1 … then 2500001
… then only software knows run number

Behavior of art root output module opens files for each sub run encountered.

We have to be careful at Data Logger to avoid subrun out of order .. because of groups of 2500..

Requirement: avoid multiple files for subruns (< 1% of subruns)

During debugging, we might product many small subrun files.. (efficient at multiple levels).. Can we have an option to group subruns? There is an option to not start new files. Can we specify level of concatenation? Or do we add an extra concatenation step? Do we care?

500 MB/s ⇒ implies ~4 Data loggers. How do we concatenate?

Really want at least one subrun per file.