The point of my calculation was to determine the average data output rate of the EMU system in realistic high-rate LHC conditions. To get this I take the data volume created by a muon track "stub" in a CSC (simply an LCT with associated L1A, i.e. a "CSC event") times the average CSC occupancy during a typical 3 BX period (minimum bias). The assumption that L1As will usually occur during a "typical" 3 BX period is not a particularly good assumption, and that's why Darin made the "L1A enrichment factor" calculations that contribute an extra 60% to the occupancy. We use 3 BX because this is our L1A-LCT coincidence window, based on the +/- 1 BX uncertainty in the Cathode LCT timing. All CSC data must pass through the EMU DDUs.
I have inherently assumed that through-going muon tracks will pass through CSCs connected to different DDUs; i.e. there is a one-to-one relation between a DDU and the CSC event. This is reasonable in that we plan to stagger our DMB-DDU connections in phi from station-to-station such that the data load from a few good muons should be shared by several DDUs. It should be relatively rare to see a DDU with multiple-DMBs to readout for the same event (although it will happen occassionally of course). It is important to note that DDUs with no data for an event will still send an empty header (48 bytes); every DDU will respond to every L1A. Please see the DDU Homepage (particularly the Output Data Format) for details.
This is how I determined the data readout volume for a single CSC event (assumed as identical to 1 event in a DDU, see above). You cannot directly apply this result for calibration or other test conditions (see below). I will try to describe my assumptions clearly so you can make modifications for other cases. Keep in mind that I made this calculation ~2 years ago and a lot has changed since then.
I assumed that 1.5 CFEBs were hit per CLCT on average. This is a little bit conservative, but not excessive. It is a matter of how we decide to trigger a front end neighbor board. We can program the CLCT overlap region (area for an LCT to trigger the neighbor board) to be as small as 1 strip or as large as 8 strips; I assumed a 4-strip wide overlap, which yields the 1.5 triggered CFEB average. It now seems more likely that we will use a 2-strip boundary, so 1.25 CFEBs on average is a better estimate. Please keep in mind that I have not added any extra factors for multiple muons (LCTs) per CSC, but this should only be a few % effect at most.
For 8 time-samples there are 1600 bytes per CFEB (3200 for 16 time-samples). Add to this my per-CSC estimates (from UCLA) for the TMB (56 bytes in minimum readout mode), ALCT (496 bytes) and DMB (24 bytes) data, plus the DDU event headers (48 bytes). This gives the 8-sample single CSC average size as 3024 bytes, while 16-samples gives 5424 bytes.
The TMB and ALCT sizes may have changed since 2 years ago (smaller?). In particular I think that Alex Madorsky has programmed a partial ALCT readout mode (for use at high LHC rates) such that only the AFEBs with an "ALCT hit" get read out. If true then you will need to determine the average number of AFEBs hit and scale the size appropriately. Also, if you turn on the CLCT triad readout then the TMB data size will increase substantially. Of course I assumed that the "TMB Scope" data will be disabled during data taking at LHC, so adjust accordingly.
For calibration events: a single CSC calibration event (5 CFEBs) has 8624 bytes (16624 for 16 samples). A full baseline DDU calibration event (no ME4/2) with 13 CSCs has 63 CFEBs (recall that ME1/3 has only 4 CFEBs per CSC) which will yield 108336 bytes (209136 bytes for 16 samples). To include the effect of the ME4/2 upgrade you must add 2 CSCs with 5 CFEBs each, yielding 125488 bytes per DDU (242288 bytes for 16 samples).
For "empty" events: any DDU with no CSC data corresponding to a given L1A will transmit 48 bytes for the event.
Errors Detected and Reported by DDU:
See the DDU Output Format page for details. The DDU Status/Error codes are specified in bits 63-32 of Header3 and Trailer-1 in the DDU data stream. I expect that the FMM bits that we send to the CMS Fast control system will be taken from combinations of these bits (to be determined). This logic is contained in an FPGA and can be tuned or modified as needed.