The MACRO-WFD mail list subscribers have already been exposed to the
issue of WFD readout byte limit and how we are concerned about its
possible effect during the acquisition's data-write-to-disk process
on a possible GC candidate in MACRO.
Today we (EK/IK/A. Baldini) performed a short test in order to have
some idea of what this might mean on *single* events with *high* multiplicity.
*All* LEDs in SM2 (i.e. 77 counters) were fired in order to create
~0.5us/~1.5V PMT pulses. It was intentionally chosen to fire the PMTs
*above* the ERPmuon level so that to include full SM readout of WFDs.
Input LED pulse characteristics: 3.5Volts for 0.5usec (all Vert/Horiz).
Sample PMT signal seen on horizontal 2B01: 0.5us duration, ~1-2V (stepping up)
Sample PMT signal seen on vertical 2W01: 0.1us duration, ~1V (stepping up)
We didn't exercise what is the maximum single counter rate that
the ACQ can handle. Given the time available for the test we thought the
maximum multiplicity within a single event is more indicative.
We can plan on performing similar tests with single counter and variable
rate if you think is necessary.
60,000 WFD readout byte limit -- RUN13866 (uV1/4/6 in ACQ)
==========================================================
1st event 15:36:00 (UT clock); WFD lights RED (stopped WFDs), almost
certainly computer busy for 10.5 seconds
2nd event 15:45:00 (UT clock); WFD lights RED (stopped WFDs), almost
certainly computer busy for 10.5 seconds
3rd event 15:45:05 (UT clock); WFD lights RED (stopped WFDs), almost
certainly computer busy from previous event.
40,000 WFD readout byte limit -- RUN13867 (uV1/4/6 in ACQ)
==========================================================
1st event 15:49:15 (UT clock); WFD lights RED (stopped WFDs), almost
certainly computer busy for 8.2 seconds
2nd event 16:01:35 (UT clock); WFD lights RED (stopped WFDs), almost
certainly computer busy for 9.8 seconds
3rd event 16:01:40 (UT clock); WFD lights RED (stopped WFDs), almost
certainly computer busy from previous event.
During both of these RUNs, WFD LED calibration runs (on VSMAC1) with heavy
WFD readout were performed in uV3, i.e., there was already a loaded local
ethernet through which the GC events had to go through.
Alessandro was looking at the PISA online monitor at the same moment.
All events were collected with almost 100% efficiency; 75 counters were
reported as counters hit (we can't be actually sure that all 77 LEDs did fire).
I looked offline in the ERPGC data for RUN 13866; the simulated high
multiplicity events are in event # 625 and 727 and there's nothing missing.
Bottom line; there's practically no observable difference in the way
the acquisition handles possible GC candidates between WFD readout limit
of 40K (the limit until 15APR96) and 60K. We are at this moment running
with a WFD readout limit of 50K. What is definitely affected in all
circumstances though is the dead time of the acquisition (not of PHRASE
or ERPGC) on high-multiplicity events that involve a lot of WFD readout.
--Erik K.