(r18) ApprovedPlotsDAQ20082010 < AtlasPublic

%ATLASPUBLICHEADER%


---+!!<nop>Approved DAQ Plots
%TOC%     <!--optional-->
%STARTINCLUDE%

---++ Introduction

The DAQ/HLT collision periods, single-beam, commissioning and performance plots below are approved to be shown by ATLAS speakers at conferences and similar events.  

<b>Please do not add figures on your own.</b> Contact the [[mailto:david.francis@cern.ch][DAQ project leader]] in case of questions and/or suggestions.

---++Figures
SDX_2nd_floor.png
<table class="twikiTable" width="100%" bgcolor=#f5f5fa  border=1 cellpadding=10 cellspacing=10>
<tr>
 <td bgcolor=#eeeeee>ATLAS HLT farms and Servers.
</td><td align="center">
[[%ATTACHURL%/SDX_2nd_floor.png][CLICK HERE TO DOWNLOAD THE LARGE FILE]] 
<img src="%ATTACHURLPATH%/SDX_2nd_floor.png"  width='300' height='220' /> </td></tr>
<tr>
<td bgcolor=#eeeeee>The overview of ATLAS DAQ system
</td><td align="center"> [[%ATTACHURL%/daq_view.pdf]] </td> </tr>
<tr> <td bgcolor=#eeeeee>Cosmic data since Sept 13, 2008. 216 M events.
400,000 files in 21 inclusive streams.
</td><td align="center">
[[%ATTACHURL%/image13.png][CLICK HERE TO DOWNLOAD THE LARGE FILE]] 
<img src="%ATTACHURLPATH%/image13.png"  width='300' height='220' /> </td></tr>
<tr>
<td bgcolor=#eeeeee>Cosmic data since Sept 13, 2008. 216 M events collected.
400,000 files in 21 inclusive streams.
</td><td align="center">
[[%ATTACHURLPATH%/image14.png][CLICK HERE TO DOWNLOAD THE LARGE FILE]]
<img src="%ATTACHURLPATH%/image14.png"  width='300' height='220' /> </td></tr>
<tr>
<td bgcolor=#eeeeee>The cosmic data in 2008, distributed across streams
</td><td align="center"> [[%ATTACHURL%/Streams.pdf]] </td> </tr>
<tr>
<td bgcolor=#eeeeee>The cosmic data in 2008, distributed across streams - Pie
</td><td align="center"> [[%ATTACHURL%/Streams_pie.pdf]] </td> </tr>
<tr>
<td bgcolor=#eeeeee>The cosmic data in 2008, details of debug stream
</td><td align="center"> [[%ATTACHURL%/streams_d.pdf]] </td> </tr>
<tr>
<td bgcolor=#eeeeee>The cosmic data in 2008, details of calibration stream
</td><td align="center"> [[%ATTACHURL%/streams_c.pdf]] </td> </tr>
<tr>
<td bgcolor=#eeeeee>The cosmic data in 2008, details of physics stream
</td><td align="center"> [[%ATTACHURL%/streams_p.pdf]] </td> </tr>
<tr>
<td bgcolor=#eeeeee>Event Building rate in 2008. 0.8 Mbyte event size.
Overnight Run. Dips are because of the automatic cron jobs.</td><td align="center">
[[%ATTACHURLPATH%/image7.png][CLICK HERE TO DOWNLOAD THE LARGE FILE]]
<img src="%ATTACHURLPATH%/image7.png"  width='300' height='220' /> </td></tr>
<tr>
<td bgcolor=#eeeeee>
ROS request EB and LVL2 Rates in an ATLAS combined cosmic run. 
The  run number is 91900 which was triggered by RPC and L1Calo.
The EB request rate is 100 Hz, the ROSs of the detectors participating to LVL2 algorithms 
see more request rate. The high rate of ID requests is due to the various full scan tracking 
algorithms. The rate on TILE is due to an algorithm doing full scan to find muon MIP signal.
</td><td align="center">
[[%ATTACHURLPATH%/RequestRateL2EB.png][CLICK HERE TO DOWNLOAD THE LARGE FILE]]
<img src="%ATTACHURLPATH%/RequestRateL2EB.png"  width='300' height='220' /> </td></tr>

<tr>
<td bgcolor=#eeeeee>
The Data Taking Efficiency, defined as the ratio of the running time during beam time to beam time, is shown. The running time incorporates the dead time fraction during each Luminosity Block reported by the Central Trigger Processor. The beam time is defined by the presence of two circulating stable beams. The width of each bar is a measure of the stable beam (shown in gray) availability during LHC fills. Each green bar corresponds to an average efficiency calculated during a fill period. The absence of filled bars indicates a period of no stable beams. Reasons for lower efficiency are stop of the run during beam time to work on a subsystem and possible trigger holds due to a sub-system issuing busy for a brief period of time. Average efficiency calculated over the whole period is 96.5%.
</td><td align="center">
[[%ATTACHURL%/eff_fill.pdf][eff_fill.pdf]]
</td></tr>


<tr>
<td bgcolor=#eeeeee>
The Data Taking Efficiency, defined as the ratio of the running time during beam time to beam time, is shown. The running time incorporates the dead time fraction during each Luminosity Block reported by the Central Trigger Processor. The beam time is defined by the presence of two circulating stable beams. The width of each bar is a measure of the stable beam (shown in gray) availability during 24 hours. Each green bar corresponds to an average efficiency calculated for a period of 24 hours. The absence of filled bars indicates a period of no stable beams. Reasons for lower efficiency are stop of the run during beam time to work on a subsystem and possible trigger holds due to a sub-system issuing busy for a brief period of time. Average efficiency, calculated every 24 hours for the last 24 hours , over the whole period is 96.5%.
</td><td align="center">
  [[%ATTACHURL%/eff_24h.pdf][eff_24h.pdf]]: 
</td></tr>


<tr>
<td bgcolor=#eeeeee>
The Data Taking Efficiency, defined as the ratio of the running time during beam time to beam time, is shown. The running time incorporates the dead time fraction during each Luminosity Block reported by the Central Trigger Processor. The beam time is defined by the presence of two circulating stable beams. The width of each bar is a measure of the stable beam (shown in gray) availability during 24 hours. Each green bar corresponds to an average efficiency calculated for a period of 24 hours. The absence of filled bars indicates a period of no stable beams. Reasons for lower efficiency are stop of the run during beam time to work on a subsystem and possible trigger holds due to a sub-system issuing busy for a brief period of time. Average efficiency, calculated every 24 hours for the last 24 hours, over the whole period is 96.5%.
</td><td align="center">
 [[%ATTACHURL%/filled_graphs-1.pdf][filled_graphs-1.pdf]]
</td></tr>

<tr>
<td bgcolor=#eeeeee>
The Data Taking Efficiency, defined as the ratio of the running time during beam time to beam time, is shown. The running time incorporates the dead time fraction during each Luminosity Block reported by the Central Trigger Processor. The beam time is defined by the presence of two circulating stable beams. Each point corresponds to an average efficiency calculated for a period of 24 hours. The size of the horizontal error bars on each data point is a measure of the stable beam availability during 24 hours. The longest bar corresponds to 24 hours. The absence of data points indicates a period of no stable beams. Reasons for lower efficiency are stop of the run during beam time to work on a subsystem and possible trigger holds due to a sub-system issuing busy for a brief period of time. Average efficiency, calculated every 24 hours for the last 24 hours, over the whole period is 96.5%.
</td><td align="center">
 [[%ATTACHURL%/eff_error.pdf][eff_error.pdf]]
</td></tr>


<tr>
<td bgcolor=#eeeeee>
In the online display screenshot, the beam time, defined by the presence of two circulating stable beams, the run status and the data taking efficiency are shown in blue, green and red respectively. The Data Taking Efficiency is defined as the ratio of the running time during beam time to beam time. The running time incorporates the dead time fraction during each Luminosity Block reported by the Central Trigger Processor. The blue and green curves have binary scale (on/off) indicating the presence of stable beams and ongoing ATLAS run. Reasons for lower efficiency are stop of the run during beam time to work on a subsystem and possible trigger holds due to a sub-system issuing busy for a brief period of time.
</td><td align="center">
<img src="%ATTACHURLPATH%/02May_eff-1.jpg" alt="02May_eff-1.jpg" width='374' height='140' />
</td></tr>



<tr>
<td bgcolor=#eeeeee>
* for the next 2 plots*
   * Run Efficiency = (RunningTimeDuringBeam – DeadTime)/(BeamTime)
   * RunningTimeDuringBeam = ATLAS partition in RUNING state
   * DeadTime is the sum of dead times for all lumi blocks (LB) during beam
   * Dead Time  for each LB is calculated from Central Trigger Processor data using values after prescaling:
   * DeadTime = ((L1_before_veto – L1_after_veto)/L1_before_veto)*(LB duration)
   * L1 data source:  L1_MBTS_2 Trigger
   * BeamTime = Both beams and stable beams flags are set.
   * ATLAS Run efficiency is calculated for 2 independent conditions: “ATLAS running” and “ATLAS running while Ready for Physics”.
Prior to the declaration of 'stable beams' some detector systems are in a standby state (e.g. reduced low and/or high voltages). "ATLAS Ready for Physics" condition is defined by 'stable beams' and detector systems at their operational settings together with a High Level Trigger menu corresponding to these settings.
   * Covered time interval:  30 Mar 08h00 -  11 October 08h00
</td><td align="center">
</td></tr>


<tr>
<td bgcolor=#eeeeee>
The weekly averages of three independent quantities, ATLAS Run Efficiency, ATLAS Run Efficiency while Ready for Physics and the stable beam availability are shown. Note that the efficiencies are not luminosity weighted.
The Run Efficiency is defined as the ratio of the running time during beam time to beam time. The running time incorporates the dead time fraction during each Luminosity Block reported by the Central Trigger Processor. The beam time is defined by the presence of two circulating stable beams. 
The width of each bar represents a week in which the availability of stable beams are shown with the red histogram with the scale on the right hand side. The average run efficiency calculated during each week is shown by the filled green (ATLAS is running) and grey (ATLAS is running while Ready for Physics) histograms. The absence of a bar in the plot indicates a week with no stable beams.
Reasons for lower efficiency are stop of the run during beam time to work on a subsystem and possible trigger holds due to a sub-system issuing busy for a brief period of time.
Average efficiency calculated over the whole period is 96.5% and 93.0% for “ATLAS Ready for Physics” condition.

</td><td align="center">
 [[%ATTACHURL%/eff-30_03-12_10.pdf][eff-30_03-12_10.pdf]]
</td></tr>


<tr>
<td bgcolor=#eeeeee>
Three independent quantities, LHC stable beam availability (yellow), ATLAS running (green) and ATLAS running while Ready for Physics (grey) accumulated times are shown. Note that the durations are not luminosity weighted.
The beam availability is defined by the presence of two circulating stable beams. The running time incorporates the dead time fraction during each Luminosity Block reported by the Central Trigger Processor. 
The flat sections of the curves indicate periods of no stable beams. The lower values of accumulated run times with respect to stable beam time indicate efficiency losses during runs. 
Reasons for lower efficiency are stop of the run during beam time to work on a subsystem and possible trigger holds due to a sub-system issuing busy for a brief period of time.  
Average efficiency calculated over the whole period is 96.5% and 93.0% for “ATLAS Ready for Physics” condition.
</td><td align="center">
[[%ATTACHURL%/runtime_30-03_30_10.pdf][runtime_30-03_30_10.pdf]]
</td></tr>


<tr>
<td bgcolor=#eeeeee>
Resource allocation curves for the HLT according to the TDAQ paper model, 
using as constraint the Level-2 latency and the global output rate. 
Fixing the measured latency of the EF, it is possible to choose the operating point (i.e. the number of XPU racks dedicate to each trigger level) by fixing the event building rate.
</td><td align="center">
[[%ATTACHURL%/paper_model.jpg][paper_model.jpg]]
</td></tr>


<tr>
<td bgcolor=#eeeeee>
Distribution of processing time per event in the ATLAS Event Filter farm; 
each color corresponds to a family of processors. The average processing time for each family is shown in the box.
</td><td align="center">
<img src="%ATTACHURLPATH%/CPUgen.png" alt="CPUgen.png" width='696' height='472' /> 
<img src="%ATTACHURLPATH%/CPUgen2.png" alt="CPUgen2.png" width='696' height='472' /> 
</td></tr>



</table>

---++Links

   * [[?][DAQ main Wiki]]

<!--***********************************************************-->
<!--Do NOT remove the remaining lines, but add requested info as appropriate-->
<!--***********************************************************-->

-----
<!--Please add the name of someone who is responsible for this page so that he/she can be contacted if changes are needed.
The creator's name will be added by default, but this can be replaced if appropriate.
Put the name first, without dashes.-->
%RESPONSIBLE% DAQ Project Leader %BR%
<!--Once this page has been reviewed, please add the name and the date e.g. Main.StephenHaywood - 31 Oct 2006 -->
%REVIEW% *Never reviewed*

%STOPINCLUDE%
   * [[%ATTACHURL%/daq_view.pdf][daq_view.pdf]]: 3_DAQ_Levels

     

   * [[%ATTACHURL%/eff-30_03-12_10.pdf][eff-30_03-12_10.pdf]]: Efficiency between 30 March and 12 October

   * [[%ATTACHURL%/runtime_30-03_30_10.pdf][runtime_30-03_30_10.pdf]]: runtime Between 30 March and 12 OCtober

   * [[%ATTACHURL%/LumiCPU.pdf][LumiCPU.pdf]]: CPU Usage in the Event Filter farm, as a function of the luminosity. Each point corresponds to the peak of the CPU usage averaged over the entire EF farm, for a specific run; the peak corresponds in time to the highest luminosity at beginning of the fill. The points are indicatively grouped per different trigger menus.

   * [[%ATTACHURL%/ROS_TDAQWeek_pg12.pdf][ROS_TDAQWeek_pg12.pdf]]: Rate limits on ROS and their improvement with CPU update, as measured for 2 ROLs per RoI and two Gbit Ethernet links.

Attachments

Topic attachments
I	Attachment	History	Action	Size	Date	Who	Comment
jpg	02May_eff-1.jpg	r1	manage	151.0 K	2010-05-25 - 17:31	GokhanUnel	In the online display screenshot, the beam time, defined by the presence of two circulating stable beams, the run status and the data taking efficiency are shown in blue, green and red respectively. The Data Taking Efficiency is defined as the ratio of the running time during beam time to beam time. The running time incorporates the dead time fraction during each Luminosity Block reported by the Central Trigger Processor. The blue and green curves have binary scale (on/off) indicating the presence of stable beams and ongoing ATLAS run. Reasons for lower efficiency are stop of the run during beam time to work on a subsystem and possible trigger holds due to a sub-system issuing busy for a brief period of time.
jpg	02May_rt-1.jpg	r1	manage	144.3 K	2010-05-25 - 17:32	GokhanUnel	In the online display screenshot, the Level1 rate, the beam time, defined by the presence of two circulating stable beams and the run status are shown in red, blue and green, respectively. The blue and green curves have binary scale (on/off) indicating the presence of stable beams and ongoing ATLAS run. Reasons for no or low LVL1 rate are stop of the run during beam time to work on a subsystem (e.g. at 19:00 in this plot) and possible trigger holds due to a sub-system issuing busy for a brief period of time (e.g. at 17:30 in this plot).
png	CPUgen.png	r1	manage	18.2 K	2011-09-15 - 14:50	SergioBallestrero	EF event processing time for different CPU generations
png	CPUgen2.png	r1	manage	48.6 K	2011-11-16 - 19:57	EnricoPasquqlucci	EF event processing time for different CPU generations
pdf	LumiCPU.pdf	r1	manage	26.6 K	2011-09-15 - 14:49	SergioBallestrero	CPU Usage in the Event Filter farm, as a function of the luminosity. Each point corresponds to the peak of the CPU usage averaged over the entire EF farm, for a specific run; the peak corresponds in time to the highest luminosity at beginning of the fill. The points are indicatively grouped per different trigger menus.
pdf	ROS_TDAQWeek_pg12.pdf	r1	manage	27.7 K	2011-09-15 - 15:03	SergioBallestrero	Rate limits on ROS and their improvement with CPU update, as measured for 2 ROLs per RoI and two Gbit Ethernet links.
png	RequestRateL2EB.png	r1	manage	8.9 K	2009-03-05 - 18:15	GokhanUnel	ROS request EB and LVL2 Rates in an ATLAS combined cosmic run.
png	SDX_2nd_floor.png	r1	manage	1585.6 K	2009-03-05 - 16:35	GokhanUnel	SDX 2nd floor, CFS, LFS and XPU nodes as of November 2008
pdf	Streams.pdf	r2 r1	manage	15.0 K	2009-03-10 - 15:11	GokhanUnel	Cosmic_data_streams 2008
pdf	Streams_pie.pdf	r1	manage	17.2 K	2009-03-10 - 15:17	GokhanUnel	The cosmic data in 2008, distributed across streams
pdf	daq_view.pdf	r1	manage	40.9 K	2009-02-26 - 23:02	GokhanUnel	3_DAQ_Levels
pdf	eff-30_03-12_10.pdf	r1	manage	47.0 K	2010-11-01 - 17:19	GokhanUnel	Efficiency between 30 March and 12 October
pdf	eff_24h.pdf	r1	manage	13.7 K	2010-05-25 - 17:28	GokhanUnel	The Data Taking Efficiency, defined as the ratio of the running time during beam time to beam time, is shown. The running time incorporates the dead time fraction during each Luminosity Block reported by the Central Trigger Processor. The beam time is defined by the presence of two circulating stable beams. The width of each bar is a measure of the stable beam (shown in gray) availability during 24 hours. Each green bar corresponds to an average efficiency calculated for a period of 24 hours. The absence of filled bars indicates a period of no stable beams. Reasons for lower efficiency are stop of the run during beam time to work on a subsystem and possible trigger holds due to a sub-system issuing busy for a brief period of time. Average efficiency, calculated every 24 hours for the last 24 hours , over the whole period is 96.5%.
pdf	eff_error.pdf	r1	manage	13.9 K	2010-05-25 - 17:30	GokhanUnel	The Data Taking Efficiency, defined as the ratio of the running time during beam time to beam time, is shown. The running time incorporates the dead time fraction during each Luminosity Block reported by the Central Trigger Processor. The beam time is defined by the presence of two circulating stable beams. Each point corresponds to an average efficiency calculated for a period of 24 hours. The size of the horizontal error bars on each data point is a measure of the stable beam availability during 24 hours. The longest bar corresponds to 24 hours. The absence of data points indicates a period of no stable beams. Reasons for lower efficiency are stop of the run during beam time to work on a subsystem and possible trigger holds due to a sub-system issuing busy for a brief period of time. Average efficiency, calculated every 24 hours for the last 24 hours, over the whole period is 96.5%.
pdf	eff_fill.pdf	r1	manage	13.6 K	2010-05-25 - 17:22	GokhanUnel	The Data Taking Efficiency, defined as the ratio of the running time during beam time to beam time, is shown. The running time incorporates the dead time fraction during each Luminosity Block reported by the Central Trigger Processor. The beam time is defined by the presence of two circulating stable beams. The width of each bar is a measure of the stable beam (shown in gray) availability during LHC fills. Each green bar corresponds to an average efficiency calculated during a fill period. The absence of filled bars indicates a period of no stable beams. Reasons for lower efficiency are stop of the run during beam time to work on a subsystem and possible trigger holds due to a sub-system issuing busy for a brief period of time. Average efficiency calculated over the whole period is 96.5%.
pdf	filled_graphs-1.pdf	r1	manage	12.9 K	2010-05-25 - 17:30	GokhanUnel	The Data Taking Efficiency, defined as the ratio of the running time during beam time to beam time, is shown. The running time incorporates the dead time fraction during each Luminosity Block reported by the Central Trigger Processor. The beam time is defined by the presence of two circulating stable beams. The width of each bar is a measure of the stable beam (shown in gray) availability during 24 hours. Each green bar corresponds to an average efficiency calculated for a period of 24 hours. The absence of filled bars indicates a period of no stable beams. Reasons for lower efficiency are stop of the run during beam time to work on a subsystem and possible trigger holds due to a sub-system issuing busy for a brief period of time. Average efficiency, calculated every 24 hours for the last 24 hours, over the whole period is 96.5%.
png	image13.png	r1	manage	34.6 K	2009-02-26 - 23:03	GokhanUnel	cosmic_data_days
png	image14.png	r1	manage	32.7 K	2009-02-26 - 23:04	GokhanUnel	cosmic_data_runs
png	image7.png	r1	manage	243.1 K	2009-02-27 - 15:23	GokhanUnel	EventBuilding Rate , overnight run with 800Kb events.
jpg	paper_model.jpg	r1	manage	44.1 K	2011-11-16 - 19:58	EnricoPasquqlucci	Determination of TDAQ operating point according to the TDAQ paper model
pdf	runtime_30-03_30_10.pdf	r1	manage	34.5 K	2010-11-01 - 17:20	GokhanUnel	runtime Between 30 March and 12 OCtober
pdf	streams_c.pdf	r2 r1	manage	50.5 K	2009-03-10 - 15:14	GokhanUnel	Cosmic_data_streams 2008 Details of Calibration stream
pdf	streams_d.pdf	r2 r1	manage	14.5 K	2009-03-10 - 15:15	GokhanUnel	Cosmic_data_streams 2008 Details of Debug stream
pdf	streams_p.pdf	r2 r1	manage	16.6 K	2009-03-10 - 15:15	GokhanUnel	Cosmic_data_streams 2008 Details of Physics stream

Topic revision: r18 - 2011-11-17 - EnricoPasquqlucci

Account
- Log In

- Cern Search
- TWiki Search
- Google Search
Atlas All webs

~~Edit~~
~~Attach~~