From: Olga Driga <olga.driga@cern.ch>
Subject: BRILDAQ Workshop minutes
Date: 19 Jun 2014 17:24:39 GMT+2
To: David Peter Stickland <david.peter.stickland@cern.ch>, Zhen Xie <Zhen.Xie@cern.ch>, Keith Jarid Rose <keith.jarid.rose@cern.ch>, "Willard Johns" <Willard.Johns@cern.ch>, Leonard Jessica <leonardj@ifh.de>, "Stella Orfanelli" <Styliani.Orfanelli@cern.ch>, Tosi Nicolò <nicko.t87@gmail.com>, Arkady Lokhovitskiy <Arkady.Lokhovitskiy@cern.ch>, Jeroen Hegeman <jeroen.hegeman@gmail.com>, Christoph Schwick <Christoph.Schwick@cern.ch>, Anne Dabrowski <Anne.Evelyn.Dabrowski@cern.ch>, Daniel Marlow <marlow@princeton.edu>, Roberval Walsh Bastos Rangel <roberval.walsh@cern.ch>, Dean Andrew Hidas <dean.andrew.hidas@cern.ch>, "wolfgang.lohmann@desy.de" <wolfgang.lohmann@desy.de>, "Agnieszka Anna Zagozdzinska" <a.zago@cern.ch>
Cc: "cmswbm-support (CMS Online Web Based Monitoring Support)" <cmswbm-support@cern.ch>

Hi everyone,

Please find the first part of notes of the BRILDAQ workshop below.
The second part will be followed by Stella.

Best wishes,
Olga

Minutes

David’s presentation.

The general scheme of the lumiDAQ was presented. He indicated that the core data from LHC/DIP will be unpacked by a DIP receiver/publisher to the eventing bus. For the monitoring the will be a number of plots which characterize the operations. It is suggested to do 24 hour summary as well as fill summary. For online monitoring is is proposed to reuse the existing one. Most of the quantities are already in WBM monitoring, but there is an advantage of having a zoomable plots in hand by online monitoring system. It is also suggested to use the dashboard offere by the xdaq to create the overviews of what’s happeninh in the system. Data receiver works is on teh way, whereas data processor is less advanced. Need of more people to do it.

Discussion:

Question: Dan indicated, that the design which is proposed in the slides is diffrent from what is documented/agreed. The difference is in the eventing bus, which is in between all the components. If the evnting fails, all the systems fail.
Answer: The eventing bus is redundant (has to run on more then one machine).

Q: What is the purpose of investing efforts in development?
A: One can reduce the number of servers used in the system.

Q: The eventing becomes a single point of failure.
A: Eventing is a multiple channel component.

Q: From the point of view of robustness of the system we do not need to bind the independent components. This will introduces an additional point of falure.
A: Eventing can be run on a powerful computer separately for each subsystem.

Comment: We need to have the design and the drawing which everyone uses, as there are many people working on the lumiDAQ. Otherwise we can end up of making many efforts in vain.

Zhen’s presenation

Zhen presented test and developments she has done for the Eventing Bus. The has prepared the rpms for the new xDAQ release. She indicated, that the existing BRIL Java server will be reused. She has also performed the xDAQ Monitoring and infrastructure testing. For the moment she was unable to do the TSDS flashlist, but she will have a session with xDAQ team next week to see this. Zhen is testing eventing using 2 servers. She a bug, which is now fixed. She measured, that it requires ~2 sec. to backup. She notes, that all users must have the identical eventing specifications. Mismatch in post numbers or server order is not tolerated.

She explain the common formalities of teh eventing and gives example of the specifications. The technology schema is neutral, the data can be analyzed with python. Common definitions and descriptions can be defined in one file.  Only 4 types of frequency are supported: 1, 4, 64 nibbles or a run. Packages which Zhen prepared are ready to release, the include the general purpose scripts and eventing packages, storage services, etc.

Synchronization issue: It might be not possible to synchronize even within 64 nibbles, because one has to catch the boarder between 4 and 64 nibbles.

LumiDAQ need to know, what CMS is doing to figure out exactly how much lumi was taken during the run.

The main parameters which are needed:
-to get from TCDS start and end of the run and 1 or 4 or 64 nibble boundary.
the deadtime calculation might be different for in and out of run. The calculation is needed.

Discussion:

Comment: It is proposed to rediscuss the synchronization issue later to try to find a cleaned decision.

Comment: It is proposed that BRIL and WBM should be synchronized. BRIL has to come up with the solution for WBM. Which quantity to use?

Olga’s presentation

The results of the uTCA readout tests playing with the integration time are presented. The results give ~400 orbits for the critical readout time, which is 10 times less then the lumi nibble size and are consistent with those obtained by Peter Hansen for BHM.

The readout measurement of 6 histograms with the actual lumiDAQ stably takes less than ~0.035 seconds. Poll time is ~30 times less then readout time.

10 boards should be available in the next weeks. The tests should be repeated in 904 for the multiple board readout. We have to find a way out. A possible solution is a multiple threading readout of the boards. After tests in 904, boards will be moved to p5 for the pedestal run. It is desirable to have lumiDAQ included in the run.

The hardcoded priority scheme for choosing the default lumi is proposed. More advanced ways will be used to suggest an error to the lumi expert.

Keith’s presentation

PLT reeadout is identical to the pixel subdetector and is already extensively tested. Keith was playing with PltDAQ. He was testing publishing with the eventing. The concern is on the data size: if too big might not be possible to publish via eventing. The data size of PLT is to be defined. Testing eventing for the failure cases (what do we do if we loose a nibble, if the bandwidth substantially reduces) is in todo list. The data quality tools is also to be developed. There is still a lot of work to do, but the todo list is under control.

Discussion:

Q: PLT subsystem needs to have orbit and clock signals. Is there any module in TCDS to do that?
A: Unfortunatelly, it does not exist. It can be obtained from the BRM or the module can be made from TTC.

Jessica’s presentation:

First RHU board is manufactured and the HW test are sucessful. RHU successfully received and decoded clock and short/long BGo commands: BC0, EC0, lumi nibble/section boundary signals. For the lumi tests, some fake data generator software already exists, tests are planned. Jessica presented the data volume estimations for BCM1F. For RHU, there is no specific LumiDAQ software development yet. Jessica presented the RHU lumiDAQ scheme and plans. For the uTCA system, she presented a general scheme, data volume estimates and planning. She indicated the deadline to provide the system with basic functionality as Jan 2015.

Discussion:

Q: Is it better to test boards in 904 or p5?
A: 904 is more convenient, when the stable results are achieved, they can be moved to p5, but not until the detector is installed.

Stella’s presentation:

Stella presented the BHM electronics overview. She indicated the similarities and differences fron HF case. Due to the similarities Stella provided the extimations for the BHM based on the HF results. She also calculated the data volue for the BHM case and presented the ideas for the monitoring. Stella presented a todo list for the tests, which include extensive tests using xdaq12. She will continue the tests next week, as currently the boards are not working.