Yo,
Since we're talking about it I remind people that the protoype is
already working ... see
http://tbn18.nikhef.nl:8000/
It's not very interesting right now since the farm is only at 20%
occupancy, and there is only one job waiting (pvier VO, stuck waiting
for 15 CPUs) so that all VOs are showing a default value temporarily set
at 15 seconds (to distinguish it from that very dangerous default value
of zero).
J "lots of things are zero, but not many 15" T
On Wed, 2005-01-19 at 15:44, Jeff Templon wrote:
> 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
