Analysis

Main idea : Analyse CU beam test data to understand better the effect of GTCC and GTRC FIFO settings on tracker performance, and use the Monte-Carlo simulations to extrapolate the observed behaviour to the LAT in order to help for the determination of flight settings.

Results

See first analysis results in attachment : Presentation at SPS daily meeting September 14th

Beam test data

Here is the list of data and MC run to analyze for each FIFO configuration  :

FIFO Conf.

GTCC almost full

GTRC depth

Data run

MC run

0

64

64

700002239

 

1

64

14

700002240

 

2

64

6

700002241

 

3

64

Tree 1

700002242

 

4

64

Tree 2

700002243

 

5

122

14

700002244

 

6

122

Tree 1

700002245

 

As shown by the preliminray analysis run done during the beam test, the beam spot and position has a very strong impact on hit dsitribution per GTRC/GTCC. The beam spot and position shall be very carefully describe in the Monte-Carlo so as to enable reasonable comparisons with data.

Short discussion about FIFO settings

Here is a short synthesis about the 10^9 emails exchanged when trying to test different FIFO configurations at SPS.

Registers

Two registers can be set :
1) the GTCC Configuration register : the lowest 7 bits are used to to set the "almost full" flag. During the beamtest, this register was set to 64 hits, that
means that the CC prevents next event to be acquired if the number of hits in the FIFO is greater or equal to 65, or that no backpressure will be
applied as far as the number of hits in the FIFO is less or equal to 64. The GTCC FIFO can contain a maximum of 128 hits.

2) the GTRC CSR register : the lowest 7 bits are used to set the maximum number of hits read by each RC individualy between 0 and 64 hits. During the beamtest this register was set so as to enable each RC to read up to 64 hits. If the sum of the maximum hits per GRTC is greater than 128 hits, the GTCC buffer depth, then track finding efficiency and acceptance depend upon the rate and reconstructed event size.

There are actually other registers related to FIFO settings, namely FIFO ERROR/TOT registers that permits to limit the number of ERROR words stored in the data. These settings were adjusted following Eric Siskind advice in the CU default schema files at the end of SPS (while doing special schema files for FIFO configuration).

Why we do care about them

First goal of special FIFO settings run was to check the behaviour of the readout when using different settings and check the functionnality at first order.

Second, one can, a priori, imagine two straightforward issues link to these readout settings and that require further anaysis :
1) Throwing away hits obviously has some impact on the reconstruction : one example is that the energy in the tracker is directly evaluated from the total number of hits. These effects have to be quantified.

2) Trying to read all the hits may generate additionnal dead time, because of the backpressure due to the "almost full" flag. There is nothing simple here however as the DAQ has many levels of buffering, the one important being the 4 GTFE. Experts think that thanks to all these buffers we can afford to read many hits and fill in the GTCC FIFO without any significant effect on dead time. It may be possible to study dead time in beam test data, but anyway hard to draw conclude on what it'll be for the LAT.

From a global point of view, using beamtest data only, one cannot determine what the best FIFO flight settings have to be :
*beam spot structure, all events arrive in the same place
*DAQ software is different.
We'll have to use the Monte-Carlo and real flight data to adjust these parameters.

What about the Monte-Carlo ?

Currently, the Monte-Carlo cannot reproduce any dynamic effect (backpressure, dead time), but it is possible to reproduce saturations of buffers setting GTCC buffer size and the GTRC buffer size (even per each GTRC using an xml file). Default settings in the Monte-Carlo are a buffer depth of 128 hits for the GTCCs and 64 hits for the GTRCs.
e.s. : Although the monte carlo itself can't reproduce information about backpressure, dead time, and so forth, generating events with the monte carlo and then running those events through the test bed DOES generate precisely that information.

Real LAT data

The study of FIFO settings should also include two cosmic ray runs taken with the LAT with special FIFO configuration :
  ( GTRC limit is set to 14 and FIFO depth is set to 7 )
77004794: intSeApp_e2e_Other-TkrFifo1_0.17hr
77004795: intSeApp_e2e_Other-TkrFifo2_0.17hr

Documentation and presentations

Tracker Naming Convetions : LAT-TD-00376-01_TkrNaming.pdf
Leon's first study with the Monte-Carlo : Leon-2005March28-515GeVGammaEvents.pdf Leon-2005Sep12-Truncation.pdf
Hiro's work on LAT data : TKR-GTRC-buffer-limit.pdf

  • No labels

1 Comment

  1. Johan BREGEON

    About initial flight settings :
    The GTCC limit of 122 used in the CERN SPS BT came from the GTRC settings for tree 1 (4, 8, 8, 8, 8, 8, 16, 31, 31), not from a flat 9@14 profile. Any run taken with the flat profile but still with a GTCC limit of 122 was acquired in order to avoid switching multiple parameters simultaneously (i.e. both the GTRC settings and the GTCC setting.) If we're starting to use the flat 9@14 profile then the GTCC limit should be moved to 126.

    The source of the confusion is that the GTRC limit is applied WHILE the contents of a GTFE are being transferred (and zero-suppressed) into a GTRC buffer, but the GTCC "almost full" condition is applied BEFORE the transfer of the contents of a GTRC buffer to the GTCC FIFO begins. Another difference is that when the GTRC limit is exceeded, no error is set, but when the GTCC space limit is exceeded the "TKR FIFO overflow" error is generated (along with the projected amount of data discarded). In talking with Robert Johnson, the general feeling is that we missed the boat by not setting a status bit and saving a projected hit count when truncation occurs during the GTFE->GTRC zero suppression.

    Ultimately however, there really are two different processes: one is zero-suppression into a fixed-length buffer; the other is pushing data through a pipeline from an upstream buffer into a downstream FIFO without a protocol that supports suspending the transfer when the FIFO fills up and resuming the transfer when FIFO space again becomes available. We DO implement a suspend/resume protocol on the transfer from the EBM to the LCB, but not on the transfer from the TEM/GEM/AEM to the EBM. The technical reason for THAT is because it requires software in the RAD750 to perform "packet reassembly" to merge the pieces that the suspend/resume protocol can chop a single event into. With the limited resources available in the EBM, there was no way that we could merge multiple LATp packets for a single TEM event contribution before building them into an overall LAT event. The real underlying cause is that the LATp protocol requires the data in a single packet to be contiguous "on the wire."
    Once you stop transmission, any resumption is, by definition, a new packet. If that new packet starts with a data cell instead of a control cell (i.e. attempts to append to the previous packet), then that is an error.

    ejs