 |
 |
Hi Chris, > Hmmm, that's possibly non-optimal. The other option I'd come up with was > to use the same queues and hack whatever does the "qsub" to add --l > nodes=sl[34]-prod to get the right resource request. Is that feasable, > does anyone know what I'd have to hack? on the glite CE it is /opt/glite/bin/pbs_submit.sh I'm testing how to pass arguments job arguments to pbs. Part of the testing means also to write the script that does the translation. Developers claim it is too difficult because there is no standard way to call things in pbs. I thought they referred to the memory parameter which can be expressed in bytes and words but if we go beyond that they are also referring to class of nodes names. For example your nodes=sl[34]-prod is not standard it is your way to call a class of nodes which could be mapped for example to GlueHostOperatingSystemName for example. I think after I tested the functionality is there. There is some work to do on the standardisation of names if we want more than memory requirements to be passed to the batch system. Any comment? cheers alessandra Brew, CAJ (Chris) wrote: > Hi, > >> -----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) >> said: >>> 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 >> non-optimal, >> 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 >> target. > > >>> 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! > > Good Point! I'd not thought of that but just nfs mounting > /etc/grid-security/gridmapdir/ does that does it not? > > Thanks, > Chris. > -- Alessandra Forti NorthGrid Technical Coordinator University of Manchester