Am 03.04.2014 um 12:02 schrieb Tina Friedrich: > >> But I'm thinking some sort of consumable 'exclusive IO' complex might be >>> the way forward. (Again, lack of per node consumables a bit of a gotcha). >> >> You can have per node consumables, can't you? Once you've added the >> consumable complex to the configuration (qconf -mc), for each host do: >> >> qconf -me <hostname> >> >> And add the consumable to the complex_values line. > > Not what I meant - they can be attached to hosts, yes. They can't be > *consumed* on a per-host basis. Consumables are either per slot (when set to > 'yes') or per job (when set to 'job').
When the proposal to enhance consumables was made, also a HOST consumable was on the table. But it was only implemented at a later point in time in UGE 8.1.3 finally. -- Reuti > The latter works fine for this when using array jobs (where each task uses > one of the consumables); however, if this were a large *multi-node* (as in > MPI) parallel job, it would count as one job, and thus use one consumable. > There's no type of resource to be used on a 'you will need to use X amounts > of these on every host you run on' type of consumable, if that makes sense. > (Had this problem before with GPUs...). > >> Or have I got the wrong end of the stick again? > > Hope I explained it a bit better now... it took me a while to get my head > 'round this (actually, I think I had it explained to me by reuti on this list > a while ago...) > >>> I've figured out in the meantime that it can be achieved by submitting >>> an AR for a one-slot-per-node PE, and then submitting the array into >>> that. Not sure which option I favour, still. >> >> The AR approach sounds horrendous! > > It does doesn't it? I've gone the consumable way, and will simply have to not > use MPI. Such hardship :) > > Tina > > -- > Tina Friedrich, Computer Systems Administrator, Diamond Light Source Ltd > Diamond House, Harwell Science and Innovation Campus - 01235 77 8442 > > -- > This e-mail and any attachments may contain confidential, copyright and or > privileged material, and are for the use of the intended addressee only. If > you are not the intended addressee or an authorised recipient of the > addressee please notify us of receipt by returning the e-mail and do not use, > copy, retain, distribute or disclose the information in or attached to the > e-mail. > Any opinions expressed within this e-mail are those of the individual and not > necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot > guarantee that this e-mail or any attachments are free from viruses and we > cannot accept liability for any damage which you may sustain as a result of > software viruses which may be transmitted in or with the message. > Diamond Light Source Limited (company no. 4375679). Registered in England and > Wales with its registered office at Diamond House, Harwell Science and > Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom > > > > _______________________________________________ > users mailing list > users@gridengine.org > https://gridengine.org/mailman/listinfo/users _______________________________________________ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
