At this morning's 10am mtg we discussed the fact that the emccheck runs were running a minbias trigger at 6khz.   We decided to scale this back to 3khz, but the question remained why did this work?    The answer is simple: because the system is fast enough to run at 6khz.

In detail, this particular run had the FMS crates and QT1-4 out of the run.  I checked the various times for each crate as a function of the event number:

I show all three crates, but the BBQ was the slowest, and so is the only relavent one.  In these plots:

1.  The first million events correspond to the bare readout time measured within the QT cpu.    
2.  The second million events are the same events, but showing the elapsed time from the end of reading out the previous event, till the end of the readout of the current event.  (If there were no gap between reading events these times would be the same, but this value is dominated by the arrival time of events if that time is longer than the readout time)
3.   The third million events is the time between the trigger and the completion of the readout (this is the time relavent for trigger corruption, but if the trigger were limited by the readout of this crate the time would be roughly (30 events in trigger at a time * the readout time of each event).

The y-axis is time measured in bunch crossings (so the corruption time would be about 64k).

Obviously, the QT crates simply are keeping up...

One interesting thing is the start of the BBQ run, in which the initial 40-50k events are all significantly delayed compared to the readout time.   It appears that for some reason, the readout isn't starting for the first time until all 30 events are present... it then takes some time for the readout to catch up in the steady state.       Also, in Akio's "Trigger RCC Monitor Plots"  this peak at 40,000 bunch crossings dominates the readout time for the BBQ, despite the fact that it only lasts for a short time.   It appears that those plots only look at the first 20k events of the run.