Difference between revisions of "Event size"

From GlueXWiki
Jump to: navigation, search
m
m
Line 9: Line 9:
 
One of the results of the meeting was the formation of a steering committee to oversee the effort to understand the event size.  Members are Elliott W, David L, and Fernando B, representing the online, offline, and electronics efforts.   
 
One of the results of the meeting was the formation of a steering committee to oversee the effort to understand the event size.  Members are Elliott W, David L, and Fernando B, representing the online, offline, and electronics efforts.   
  
We met on 25-Sep-2007 to understand where we are and what needs to be done. Notes from the meeting:
+
We met on 25-Sep-2007. Notes from the meeting:
  
 
* need to undersand board occupancies, average event size/rate, and burst size/rate
 
* need to undersand board occupancies, average event size/rate, and burst size/rate

Revision as of 11:26, 27 September 2007

Introduction

The average event size determines backplane bandwidth requirements, network bandwidth requiremens, number of modules per crate, and many other things. Fortunatly the DAQ system is highly modular and scalable, so accomodating even a doubling of the event size should be no problem. I.e. more crates may be needed, and perhaps a faster RAID system, but no change in architechture would be needed. See the discussion in the minutes from the 29-Aug-2007 Online Working Group meeting dedicated to this topic.


Steering Committee

One of the results of the meeting was the formation of a steering committee to oversee the effort to understand the event size. Members are Elliott W, David L, and Fernando B, representing the online, offline, and electronics efforts.

We met on 25-Sep-2007. Notes from the meeting:

  • need to undersand board occupancies, average event size/rate, and burst size/rate
  • need to understand header sizes and what data boards generate if there are no hits
    • minimize in production boards and for production running (vs debug modes)
    • header words can be removed at many stages: on board, by ROC, by EB, in farm, and by ER
      • need to understand data rates at each stage
    • board should not put out chip-specific information, only board-level information (in production mode)
    • possible ways to recognize that all boards are reporting
      • header/trailer words for each event
      • ROC-generated bit mask for each event
      • error flags if a board did not report, no data generated
      • check periodically (not each event)
      • others?
  • renormalized (scaled) Pythia seems to be adequate
  • different types of events needed
    • physics trigger events
    • photon-induced EM background events
    • phodon-induced hadronic background events
  • background events (single or multiple) can pass trigger, or can accidentally overlap with real physics trigger
    • i.e. accidental hits vs accidental triggers
  • need backgrounds from full energy range of incident photons, including low energy photons
  • need to run MC with latest geometry, or at least one with a reasonable upper limit on material
  • need to better simulation Level 1 trigger algorithm
  • Dave estimates we need the following computing/simulation time
    • event generation goes quickly, perhaps only a few hours
    • 1 week simulation Pythia events
    • 1 week simulation EM background
    • 1 day simulation hadronic background events
  • need to understand bytes per hit for all detector/electronics combinations
    • is timing needed
    • adc + tdc vs adc only


Game Plan