Hi,
On Wed, 2005-01-19 at 14:55, Mattias Wadenstein wrote:
> On Tue, 18 Jan 2005, Laurence wrote:
>
> > About 6 months ago the experiments wanted to have one queue per VO so
> > that they could implement some ranking algorithms.
>
> It seems to be pretty useless to me, since in the end, there is just one
> queue in practice and it's dynamically scheduled by maui fairshare. At
> least in our case. Tricking pbs into giving the impression that these are
It depends on your perspective. As far as scheduling you are absolutely
correct ... there is no effect whatsoever. I am not sure how well the
LHC experiments realize this.
On the other hand, it's easy for the info provider to find out how many
jobs are in a single queue, and this is one of the things reported by
the info provider. If that number is known to correspond to a single
VO, people in that VO can use it to make a rank algorithm better than
the default one. As a simple example, in such a situation one could
rank on
-other.GlueCEStateWaitingJobs
The more jobs in 'Q' state (PBS speak here) the worse your rank is.
Sites with no 'Q' jobs would be equally ranked. Actually a reasonable
algorithm in the short term.
The long term answer is to fix the GlueCEStateEstimatedResponseTime
parameter to deal with reporting for multiple VOs. Laurence, both
Steves, and I are working on that.
JT
|