Testbed Support for GridPP member institutes
> [mailto:[log in to unmask]] On Behalf Of Henry Nebrensky said:
> Unfortunately I've been a bit under the weather and not
> really followed up on this yet.
And I was on leave last week - just catching up ...
> > Bear in mind that you need to look at the ERT for the mice
> VOView, not
> > the CE as a whole.
> Well, surely I need to look at the the ones that reflect what
> the actual job will encounter
Well, that's exactly the point of the VOView - many sites have fairshare
policies which mean that jobs from different VOs in the same queue will
have substantially different priorities.
> - e.g. that the short queue (ERT=0) has an idle CPU
> sitting and waiting - rather than some non-representative
> averaged value.
The value is supposed to represent the history of actual jobs. Have you
tried submitting some jobs to see what happens? It should be the case
that once there is some history for the provider to work with the
numbers should get more realistic - although off-hand I don't remember
exactly what the code does. As I say, you should talk to Jeff Templon if
you want more information - he currently seems to be going through all
the outstanding bugs and fixing them so this would probably be a good
time to raise any problems you see.
> There isn't any way to specify which view to use to the
> matching process, is there?
No, it matches your VO - there wouldn't be much point doing anything
else since the data for a different VO is unlikely to be relevant!
> This effect won't show up on sites that have single per-VO
> queues, but it
> seems that an increasing number are deploying shared queues
> with different time limits.
That was exactly what this was supposed to solve, i.e. the VOView should
tell you the situation for jobs for your VO regardless of what the other
VOs are doing. E.g. it may well be the case that mice jobs will run
immediately even if there's a big queue of cms jobs, or vice versa.
Scanned by iCritical.