STT Monitoring - PRELIMINARY STUDIES Silvia Tentindo-Repond FSU 14-Jan-1999 We want to be able to do STT monitoring at two levels: 1) REMOTE i.e. at HOST level (Online 'Examine') and 2) LOCAL i.e. at pre-processor level ( L2 ALPHA processor ). 1 -- REMOTE - STT Monitoring at HOST 1.1 - The 'Examine' project has accomplished the stage of design (Ref. 1,2) . Some of its parts are operative at prototype level - Examine Executable and Examine GUI - and others are under development - Examine Framework -. 1.2 - description of data flow TCP/IP protocol for communication - 1.3 - The 'Tracker Monitoring' (one of the planned Detector Examines) will monitor SMT, CFT, and STT. The 'Trigger Monitoring' will mostly provide software trigger performances and rates for each bit of each component, so in- cluding STT. Typical quantities to be monitored at HOST level ( by the Tracker Monitoring) should be @ size of clusters @ number of clusters per road @ multiplicity of hits per cluster @ list of hits in a given road @ multiplicity of STT tracks/evt @ track parameters in the Rphi plane: impact parameter track direction track curvature @ track quality ( chi square ) @ HOW MANY EVTS SEEN IN STT Typical quantities to be monitored still at HOST level (by the Trigger Monitoring) : @ time spent for digitization /per cluster or /per evt @ time spent for track reconstruction /per track or /per evt Periodically, this Examine will need to collect information sent via TCC from the Trigger Central Computer (see sect. 3),as ty- pically the hardware scalers: exact counts (how many evts) integral quantities ( luminosity) averages (livetime) The HOST Examines, through a graphic users interface GUI, provide the way to DISPLAY HISTOGRAMS of raw quantities (mentioned above) and also to do partial event reconstruction and analysis. The platform chosen by the Online group to do physics analysis is ROOT. Comparative studies of efficiencies ( STT vs CFT ) could be useful. EVENT DISPLAY through the GUI are also available. A DUMP utility allows to display the content of the raw data buffer, and is essential for rapid diagnostics made by experts. A MESSAGE interface should be able to receive and display alarm messages coming explicitely from our detector. It should also allow to display periodically STATUS information (like how much time STT has spent in active mode - waiting mode /per evt) and recent history. At each END-OF-RUN, the Examine should be able to store typical End of Run quantities, like : @ Statistics for timing @ ....... Also at End of Run, Examine should be able to store the wanted quantities in an STT Ntuple file. Through the input selection menu in the GUI window, the source entry for monitoring could be chosen to be FILE instead than DAQ, thus allowing to process data on file for special kinds of batch monitoring (f.ex. to run offline the trigger 'unbiased sample ', see next sect. ). 2 --- LOCAL - STT Monitoring at L2 pre-processor (ALPHA) 2.1 - Description of components where monitoring info is created. In L2 each pre-processor is distributed in crates. There are six crates for STT. For each preprocessor that is also an ALPHA processor crate. This is valid for CAL,FPS,CPS,CFT and MUON. At present there has been no ALPHA processor planned for STT, being the tracking information sent to GlobalL2 through CFT anyway. It comes out, from preliminary thoughts about monitoring,that pro- bably a ALPHA would be needed specifically for STT. At present, f.ex. in the CFT preprocessor, the ALPHA 'worker node' will keep track of each crate, how often they run and will accumulate basic statistics. The L2 framework watching this farm, will get more information about how much time has been spent in a given routine, or in reformatting,or in waiting before sendinf info to L3. So , in the ALPHA worker node, that is responsible to collect statistics, once every 5 seconds ( about 1.50.000 evts ) one evt special comes to that specific segment, and after that evt, statistics gets collected. Then the ALPHA administrator node sends that information to the TRIGGER CONTROL COMPUTER (TCC). Here the info is put into a buffer, copied into memory, and waits . THe TCC ( an Intel with C++,possibly NT ), will run a MONITOR INFO server, the information gets packed into blocks, and sent to the HOST. On the HOST it will be requested that the info be displayed. 2.2 - Possible monitoring in L3. L3 seems at first sight the ideal site where to make monitoring for the Trigger components: there is where Nt stations and GUI will collect all the tracking information befor sending it to the Host. During RunI, the equivalent of L3RunII ( i.e. L2RunI ), had some time charts , made for the purpose of monitoring the trigger system. The problem is about diagnosis : to L3 pass only the 'normal' data. If one piece upstream breaks, L3 cannot track back to the place, nor identify the problem. For the same reason, we address the need of having an ALPHA for the STT crates : if something goes wrong in STT, the ALPHA of CFT will only experience lack of input, and be able to report that 'data flow stopped. ***** 2.3 - Possible ways to monitor STT at L2. As it is now, this is the information that is available to be monitored at CFT ALPHA level: When the STT information is sent to CFT, there are TWO processors one keeps the pt ordered list and the other keeps the 'displaced vertex' ordered list. A third processor could be added that will be able to keep statistics, and information about clusters quality. Beacuse only tracks are sent to CFT (clusters are sent directly to L3), the ideal place to monitor on cluster hits AND tracks would be a ALPHA processor devoted to STT specifically. - ALPHAs are 64 bit processors, They use Digital PC164 to compile (and debug) programs on a DEC UNIX workstation (C++ compiler) , so they have no operative system.- Quantities that could be monitored in the STT ALPHA : @ clusters size @ number of clusters/track and /evt @ track parameters @ track quality @ number of tracks /evt @ time spent in clusters /evt @ time spent in tracking /evt @ time processor is active/waiting @ processor STATUS (On/OFF) if OFF, send MSG to TCC ( and from there to HOST ) that " STT has problems! " @ dead time in clustering @ dead time in track fitting @ ..... @ EVT DUMP ?? 2.4 - Batch Monitoring An ' Unbiased Sample ' stream will allow to record unbiased data on file. It will be essential to debug the system mostly at 'first beam' , when it will be essential to diagnostic dead time sources. As already mentioned in sect. 1, the Examine monitor is able to run in file mode and will be used for the present need 2.5 still to investigate Pac-man displays (time-in state scalers in L2) - or bar-chart (Buffer occupancy scalers - calc. Nevt )