4/24/2015 Notes

DocDB Event


Craig G., Bruno, Jonathan, Leon, Jan, Marianna, Andrey, Yuri, Luke, Andrew and Martin (taking notes)

Supernova Trigger

  • Number of Doublets (in adjacent planes) with an ADC sum above threshold are sent to GT together with the time stamp.
  • Alec points out that Michel electron are not rejected by this.
  • Slicing still needs to be finalized:
    • based on Alec's slicer
    • see Jan's CalTech talk for first effort on this
    • 4 hits with 4 TDC
  • Jan asks about the millislice duration (5 ms)
    • Leon points out that this is a DAQ configuration parameter and can in principle be changed.
    • Alec notes that this is defined in the GT.
  • I asked about the rate of NSNPackedMessages and Jan explained that the SN DDT module collects 10 messages and then sends them as an array.
    • takes us from 200 Hz (every milliblock) to 20 Hz (1 per 10 milliblocks)


  • Andrew points out that Zukai's cutoff might be as large as 3 seconds.
  • Yuri is surprised that the UpMu modules take so long.
    • He will follow up on this.

CPU Sets

  • Andrew explained that BNEVB is supposed to be on its own 2 threads, so that the default scheduler does not interfere with its operation.
  • Leon proposes that we test the DAQ with and without CPU migration.
    • If there is not noticeable difference without the CPU sets, we can run without them.
    • Perhaps we can simply tear down the CPU sets on some (or all) of the hosts. That way the migration would simply fail and we would not have to edit a bunch of start scripts.
  • An additional sleep will not solve the DDT process migration issue because the longer we sleep, the more CPU will be used on the system set and crowd out DDS.

Moon Shadow

  • Chris can have this trigger at less than 10 Hz, 75 Hz is too much.
  • Let's start with a prescale of 10 or 100 and see what the rate looks like. We can then ease off on the prescale.
  • Chris calculates the moon position for every event.
    • Alec suggests that we just calculate it once a minute.
    • Let's see what the timing of this module looks like first and if it is bad, we can optimize more.
    • I told Chris that if he is under 100 ms on a VM, there should not be a problem.