1 / 6

T0-T1 ALICE transfers

T0-T1 ALICE transfers. Yves Schutz (ALICE) WLCG-MB, 20 th July 2010 . Raw data transfers: Mechanism. Since the restart of the LHC in 2010 ALICE is using xrootd as general transfer protocol for all Tx -Ty transfers Latest version enables the 3 rd party copy (xrd3cp)

pancho
Download Presentation

T0-T1 ALICE transfers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. T0-T1 ALICE transfers Yves Schutz (ALICE) WLCG-MB, 20th July 2010

  2. Raw data transfers: Mechanism • Since the restart of the LHC in 2010 ALICE is using xrootd as general transfer protocol for all Tx-Ty transfers • Latest version enables the 3rd party copy (xrd3cp) • Implemented and already in production for FZK and CNAF • Still co-existing with xrdcp FZK CASTOR Limited number of files transferred CNAF DAQ Alien tranfer queue FTD Info about each raw data file xrd3cp NDGF MonALISA Repository AliEn Catalogue Electronic logbook DB mysql … • Automatic pass 1 reconstruction • Transfers to T1 • Storage status • Quotas per site • - Good runs • Transfer completed • Run conditions

  3. Raw data transfers: Mechanism • The number of “channels” (concurrent transfers) opened by FTD is centrally controlled by AliEn and limited to 200 concurrent transfers in TOTAL • The amount of concurrent files transferred per each T1 site is defined by the number of available resources provided by each T1 to ALICE • These numbers were presented by the experiment during the SC3 exercise and have not been changed • It does not surpasses the 50 concurrent transfers per site

  4. Raw data transfer: results During the same period the rest of the LHC VOs where achieving up to 700MB/s As expected: network is NOT an issue Example: 29-05-2010 ALICE transfers • Full runs transferred to each T1 site BUT NOT AT ONCE (remember… 50 files per time) • SE choice based on the ML tests at transfer time and THESE ML TESTS INCLUDES THE BANDWIDTH STATE • Poor and not available bandwidth eliminates the site • The bandwidth status is therefore controlled BEFORE ANY TRANSFER ATTEMPT

  5. Abusive usages: Prevention • ALICE transfers, SE usage, bandwidth status are available and monitored in ML • Actually no transfer decision is taken if any of these parameters is wrong • REMEMBER: until all these parameters are checked the files are HOT (they can be moved to any available SE at any T1) • Since the startup of the LHC NO NETWORK OR BANDWIDTH INCIDENT/ABUSE has been reported by any site or by any other LHC VO • Nevertheless, SITES ARE EXPECTED TO MONITOR THE USAGE OF THEIR BANDWIDTH AND SE STATUS BY THEMSELVES • And they can ALWAYS take prevention measures if any bandwidth or SE mishandling is observed • ACTUALLY EVEN TRIVIAL IN THE CASE OF ALICE: LIMIT THE BANDWIDTH AVAILABLE FOR THE XROOTD NODE AT YOUR SE! • ALICE will note it from ML and the ongoing transfers will finish (slowly) before excluding the usage of this SE for the next bunch of transfers • THIS does not mean this is the best procedure, this means you have the control of the transfers at you site AS EXPECTED

  6. ALICE transfers Monitoring Dashboard Gridview includes also the ALICE transfers and the throughput

More Related