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 |