 |
 |
PS > Any comment? or examples of alternative torque configurations? cheers alessandra Alessandra Forti wrote: > 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. > > > 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