About the scheduler

Having a high level user description, the scheduler decides in what way to satisfy the request. We are free to experiment with different strategies, and to change the underlying implementation. Our work has pursued different objectives.

• Distributed disk: not all sites and machines will have access to a distributed file system. By storing part of our data files on local hard disks, and keep our file catalog up to date, the scheduler can send jobs where the input is. At both RCF and PDSF we have been using this scheme in production since September 2002.
• Resource usage: since we have complete control of all the jobs submitted through the scheduler, we can embed inside the logic that allows more efficient use of resources. Our batch system, at both RCF and PDSF, uses static resources to control the number of jobs accessing NFS servers. If users submit jobs to LSF, they have to know this setup and use it correctly. The scheduler hides static resources usage, making it transparent to the users.
• GRID: we are working on a GRID implementation of the scheduler using Condor-g as the underlying batch system.

All this development goes on inside the scheduler, and user requests need not to change. In fact, job description meant for the first version of the scheduler are still valid descriptions.