RAL Tier A

1
RAL Tier A

• Tim Adye
• Rutherford Appleton Laboratory
• BaBar UK Physics Meeting
• Queen Mary, University of London
• 25th October 2006

2
Outline

• CPU Usage
• CPU Allocations
• Disk Status
• The bleak future
• Summary

3
BaBar Batch CPU Use at RAL
4
BaBar Batch Users at RAL(running at least one
non-trivial job each week)
5
CPU Allocations

• CPU Allocation
• (MAUI fairshare target)

CPU Usage (MAUI fairshare usage)
6
BaBar CPU Allocation and Usage
Farm Capacity
7
Requests and Allocations
8
Data and Storage

• Keeping up-to-date with new production
• Uses disk space freed up by-
• Tau/QED skims removed in February
• Converted R18b pointer skims to R18c deep-copy
• Removed AllEvents in August
• All old files still accessible from tape
• Except old SP5/SP6 generics, now deleted from
  tape
• Currently problems with user data disk
• /stage/babar-user1 offline since 13 Oct
• Recovering the data going slowly hope to be
  done by the end of the week
• Three 1.9 TB AWG disks
• /stage/babar-awg1/Quasi2body (was TauQED)
• /stage/babar-awg2/Quasi2body
• /stage/babar-awg3/ThreeBody

9
Three bullets we try to dodge

• BaBar disk, tape, and CPU requirements increase
  with luminosity.No change in GridPP allocations
  Jan06 to Dec08.
• PPGP cuts removed BaBar/RAL support staff
• 1.5 FTE -gt 0.25 FTE in April 2007
• No effort to import data, releases, help users,
  etc
• identified 21 BaBar-specific tasks needed to keep
  Tier A running
• GridPP proposal to remove non-Grid access by
  September 2007
• No RAL front-ends, no NFS access to user/AWG
  disks
• Continued BaBar user analysis probably impossible
• SP and/or skimming might still be possible via
  the Grid

10
Summary

• We are making good use of the resources we have
• Apart from an (understandable) lull over the
  summer
• The service works well most of the time
• Current disk problem is severe, but rare
• We are fighting hard for
• the resources we need
• the staff we need
• the non-Grid access we need