[Olympus] rates in TOFs

[Alexander Kiselev]

  Hi Alexander,

> at the moment you can just figure out which PMT has fired by reading 
> the TDC. There is no other equipment, which knows about the 
> Discriminator outputs.

  I understand that with the equipment we have installed now we are
where we are. The question is could we improve the situation with
some moderate effort. And if we come to a conclusion we should not, 
perhaps just close this topic, I have no problem with that. Naively I'd 
say that with so limited data taking time any noticeable improvement in 
effective counting rate should be considered thoroughly.

> But as far as I know we can not just read individual channels of the 
> Fastbus ADC, but only the whole module. *Maybe Philipp or Christian 
> should comment on this!*

  if that does not work, I would install 8 ADCs instead of 2 and read
out (as a whole) only those modules which have at least one hit above 
threshold. And the ADCs must be available, we had a plenty of them at 
HERMES.

> We also need to know how much we can speed up the readout without 
> harming the operation of the Fastbus sequencer.

  I'm not an expert here, but I thought we have reasonable CPUs with a 
complete local OS installed in these SFIs. Would it be possible to 1) 
read out TDCs first, 2) decode them, 3) read out only those ADCs which 
had TDC hits? I guess TDC and ADC in the same crate are read out 
sequentially anyway? If this does not sound reasonable, yet would it be 
possible to have some extra latch modules installed which would store 
discriminator status at a time of trigger decision?

  Regards,
    Alexander.


> Alexander
> 
> On Aug 24, 2011, at 9:58 AM, Alexander Kiselev wrote:
> 
> >  Hi Alexander,
> > 
> >> maybe let me add some more information about the fastbus readout.
> >> The drift chamber TDCs are zero suppressed, so the data load is 
> >> depending on the occupancy. During the commissioning we found a typical 
> >> amount of data of less than 100 bytes per detector. The TDC of the TOFs 
> >> is also of the same order. The most data is coming from the TOF ADCs, 
> >> because they are not zero suppressed. The amount of data is 524 
> >> bytes/event.
> > 
> >  may I ask once again, what would be the effort to check pattern of 
> > PMTs above threshold first, and read out only those which fired? 
> > 
> >  Regards,
> >    Alexander.
> > 
> > 
> >> The maximum rates of 1.3 kHz we could observe during the August run is 
> >> not a real hardware limit, but was a safe setting for the read out. 
> >> Philipp is now working on the optimization of it. I have no idea how 
> >> much speed we could gain.
> >> If we want to speed up with additional hardware, it would make sense to 
> >> put the TOF ADC into a third crate. To find another crate is not a 
> >> problem, as you wrote yesterday, but the SFI sequencer is the challenge. 
> >> I'm not aware of any at DESY or other labs I have access to.
> >> 
> >> Cheers,
> >> 
> >> Alexander  
> >> 
> >> On Aug 24, 2011, at 8:42 AM, Alexander Kiselev wrote:
> >> 
> >>> Good mornig colleagues,
> >>> 
> >>>> Installation of say two more crates would increase the effective readout 
> >>>> speed by a factor of almost 2, as we discussed today. This may be pretty 
> >>> 
> >>> this factor of 2 is way too optimistic I admit. Let's estimate correct 
> >>> numbers useful for further discussion. Sorry if the below calculations
> >>> look trivial.
> >>> 
> >>> Indeed numbers quoted during the Monday meeting (max readout rate 1300Hz
> >>> at 2% live time, "typical readout fastbus") have nothing to do with the
> >>> real running conditions. Let's assume ~750us average "event cycle (readout
> >>> time + waiting for next trigger)" for simplicity. 2% live time would mean
> >>> that next trigger waiting time was only ~750us*0.02=15us, so the original 
> >>> trigger load was ~67kHz. Clearly we will never run under conditions like 
> >>> this. 
> >>> 
> >>> I'd say with so large readout times we should never go beyond ~1kHz 
> >>> original trigger load (~1ms next trigger waiting time in the above 
> >>> calculations). Assuming now ~750us average readout time for simplicity, 
> >>> this would correspond to the on-tape (accepted) trigger rate of ~1/1750us 
> >>> or ~570Hz at a ~43% dead time, obviously. 
> >>> 
> >>> If we manage to decrease the readout time from ~750us to say ~400us, 
> >>> average event cycle will become 1400us for the same 1kHz trigger load, 
> >>> which would mean ~715Hz accepted trigger rate at a ~29% dead time. So 
> >>> gain would be significant, but no way close to a factor of 2.
> >>> 
> >>> It should also be mentioned that useful (ep-elastic) trigger rate at 
> >>> nominal luminosity is ~15Hz in BLAST acceptance and about the same in 
> >>> 12-degree Lumi acceptance. Even if we increase average luminosity by 
> >>> a factor of 2, trigger budget will (should!) be always dominated by  
> >>> calibration (inclusive) triggers and random coincidences. Under these
> >>> circumstances with a relatively slow readout hardware it does not make 
> >>> sense to run at higher dead times, since this causes 1) smaller 
> >>> *fraction* of ep-elastic events on tape, obviously; 2) in fact smaller 
> >>> *rate* of ep-elastic events on tape, less obvious; 3) worse signal
> >>> to background ratio if random coincidences start dominating. Derivation 
> >>> of the "best figure of merit" running strategy in terms of DAQ rates
> >>> as a function of luminosity, readout time, random coincidence scaling 
> >>> and allowed fraction of calibration triggers is a rather straightforward 
> >>> excersice, which "everybody else can do" :-)
> >>> 
> >>> Best regards,
> >>>   Alexander.
> >> 
> >> --
> >> Dr. Alexander Winnebeck
> >> winnebeck at mit.edu
> >> 
> >> Massachusetts Institute of Technology (MIT)
> >> 77 Massachusetts Avenue
> >> Bldg 26 / Rm 441
> >> 02139 Cambridge, MA, USA
> >> Tel: +1-617-253-3680
> >> 
> >> DESY
> >> Bldg 66 / Rm 002
> >> Notkestrasse 85
> >> 22603 Hamburg / Germany
> >> Tel: +49-40-8998-6402
> >> 
> >> 
> 
> --
> Dr. Alexander Winnebeck
> winnebeck at mit.edu
> 
> Massachusetts Institute of Technology (MIT)
> 77 Massachusetts Avenue
> Bldg 26 / Rm 441
> 02139 Cambridge, MA, USA
> Tel: +1-617-253-3680
> 
> DESY
> Bldg 66 / Rm 002
> Notkestrasse 85
> 22603 Hamburg / Germany
> Tel: +49-40-8998-6402
> 
>