> -----Original Message-----
> From: Testbed Support for GridPP member institutes
> [mailto:[log in to unmask]]On Behalf Of Burke, S (Stephen)
> Sent: 05 July 2007 15:41
> To: [log in to unmask]
> Subject: Re: Torque/Info System Questions
> Testbed Support for GridPP member institutes
> > [mailto:[log in to unmask]] On Behalf Of Brew, CAJ (Chris)
> > 1) Do we still need per VO queues?
> I could argue that you never did need per VO queues :) However, the
> general point is that voviews are only understood by the glite WMS. In
> theory the RB is likely to be phased out Real Soon Now so
> that shouldn't
> be a problem ... also the effect is only that scheduling is
> e.g. a VO may see a large ERT for a multi-VO queue when its jobs would
> actually start quickly because it's currently under its fairshare
> > 2) Is there any reason not to leave the second CE in place
> long term -
> > it would be useful for load balacing and upgrades to have two Ces
> > feeding jobs to the same queues but would it lead to double
> > counting of resources?
> It does lead to double-counting e.g. in gstat, but that possibly isn't
> too serious. Also there is no explicit load-balancing as such, brokers
> will just treat them as independent so the outcome will depend on
> exactly what gets published (e.g. are you running the info providers
> once or twice?) and what ranking algorithm is used - although brokers
> randomise if the ranks are equal which helps. One thing, make sure you
> have a shared pool account mapping!
You'll also need a shared software tag area.
My intention is that when the Tier 1 has multiple production CEs that we'll partition by VO, which I think minimises most of these problems.