- Table of contents
- 07/23/2013 Notes
Matthew, Louise, Barnali, Zukai, Andrew, Alec, Yuri, and Martin (taking notes)
- Beam is delayed by another few weeks.
- We will purchase more computing:
- ~150 more nodes
- 16 or 32 cores per node
- 2 GB of memory per core
- Andrew wants Alec to look into the DAQ buffer depth and see what would be left for DDT.
- Andrew wants input from everyone on this, so he can turn in his requisition during the first week of August.
- Perhaps we might also get an upgrade to the Data Logger <-> Buffer Node connection!
- We went over my slides.
- Andrew notes that the trigger bits will not be hardcoded for life, but that we should just go ahead with what Alec has plus the following changes:
ATMNU -> NUMU TRICELL -> MUONCAL TRIG_ID -> TRIG_ID_DDT (or TRIG_ID_ACCEL)
- We will call the above trigID code version 2.
- In the future, Andrew would like to have trigger blocks (e.g. Monopole from bit 14 - 20), but we will hold off on this until DAQDataFormats can handle more than 32 trigger bits. This might then be a feature of version 3.
- I asked for a convenience function to convert the trigger name string to the trigger bit and Alec will work on an automatically generated hash table for this purpose.
- Alec will also implement bound checking in
- On slide 2, we asked why the VMs were faster than the FD nodes and here is Andrew's explanation:
- FD Node: 16 * 2.0 GHz cores
- VM Node: 4 * 2.6 GHz cores
- This means that the VMs are better serially, but we get our power from running our ddt-filter in parallel on several cores.
- Andrew agrees that we should write a tech note where we start to explain the algorithms and the lower level steps (e.g. sorting and slicing). I will be in charge of compiling and editing the document. Andrew will provide me a skeleton format that is used in DAQ as well.
- Andrew wants to get CPU times from FD data rather than MC. Matthew will generate this data when we have the FD DDT infrastructure ironed out.
- Andrew will request FD and NDOS for trigger development next week while I am on shift. We will have a series of working sessions in the control room. I will send out an announcement late this week.
- I will update ART and ARTDAQ for DDT and then update all of our base releases.
ddt-filter Memory Leak¶
- Zukai looked at the Valgrind output and noticed a memory leak in the upstream DAQ modules.
- Zukai will send the Valgrind output around for us to look at.
- Matthew suggests that we have a memory leak checking wiki entry:
- Zukai will type up Valgrind instructions.
- Matthew will explain how to use it to check for leaks.
Algorithm Efficiencies and Acceptances¶
- Zukai is looking into the low level modules (starting with TDC Sort) for their efficiencies and acceptances.
- He will show some plots next week.
- Yuri met with several DAQ experts last week.
- The decision of this meeting was that we will have a separate DDTApplicationManager that will be monitored by the DAQ system.
- The DDTManager will be able to send messages to run control and the message logger about its state.
- Yuri will work on this with Kurt before he leaves for Russia.