DAQ deadtime studies

NEXT
Make New Entry, Make Followup Entry

User name Bob/Alex/Dave

Log entry time 09:32:09 on November16,2010

Entry number 340326

Followups:

keyword=DAQ deadtime studies

Work by Alex, Bob, and Dave Abbott.
Report written by Bob

We investigated the DAQ deadtime.

The main observation is that if we turn off the writing of
data to disk (EB output "none") the deadtime is stable and
the DAQ runs at 26 Mbyte/sec.

There was some marginal evidence that writing to adaql1
disks was worse, but we did see some hiccups writing to
adaql2. When there is a hiccup, the DAQ backs up and one
of the crates will not be able to send data. This shows up
as a busy signal on a crate but only if you include the busy
to after the "done" routine in CRL. The trigger routine
busy does not show it and the crate trigger busys were
stable which mean the VME transfers had a stable deadtime.

Alex seems to think that writing to his computer dvcsdaq2
is more stable, though he did see some DT fluctuations
with beam.

There was some confusion with the TS11 crate but it is ok.
With beam, this crate sees 200 usec deadtime with fluctuations
to 1 msec. This is the 1 kHz readout of the ring buffer data.
The deadtime at 150 Hz is 5 to 8 % and stable and predictable.
This also is true for the LeftHRS config because for that TS11
dominates the deadtime. What was confusing is that when beam
goes away the deadtime increases (typ. 3 msec) but this is because
we are flushing the scaler FIFO less often and there is more data.
There is nothing we can do about this if we want 1 kHz helicity
data with zero deadtime.

The options to fix the deadtime:

1. Write to adaql2 only, unless there's an emergency where we
run out of disk on adaql2. It seems this would help a little.

2. Major upgrade of computer, especially the disks. Not clear
yet what this would look like.