Thanks Reuti, I appreciate the help. Rich
-----Original Message----- From: Reuti [mailto:[email protected]] Sent: Wednesday, February 22, 2012 4:57 PM To: Maes, Richard Cc: [email protected] Subject: Re: [gridengine users] Tricky consumables problem Am 23.02.2012 um 01:36 schrieb Maes, Richard: > Reuti, > For the example below where you spec which PE to instantiate. >> $ qsub -pe ixia* 1 job.sh > > Can this accept something other than wildcards? Is there a way to make > it do REGEX? Or ranges? > For a case where I have Ixia1, Ixia2, and Ixia3, and lets says I want > one group of tests to use Ixia1 and Ixia2. I have a second group of > tests I want to run on Ixia3, > I would be cool to do > Qsub -pe ixia[12] 1 job.sh > Or even qsub -pe {ixia1,ixia2} 1 job.sh, No, the pe_name can only contain an asterisk as wildcard (or more). The REGEX would normally match one of them in the above format, but if it's a real "and" what you mean and not only one of them, you could define even more PEs. ixia1_s ixia2_s ixia3_s ixia12_d ixia13_d ixia23_d limit -pes ixia1_s,ixia12_d to jobs=1 limit -pes ixia2_s,ixia12_d to jobs=1 ... (Each in a separate RQS on its own, as they are not disjunct and only the first matching one will be honored.) -pe ixia*_s 2 (for a single one) -pe ixia*_d 2 (for any two) (Don't buy more ixia blades... :-D it will get convoluted.) -- Reuti > But I don't think either of those works. > Rich > > > -----Original Message----- > From: Reuti [mailto:[email protected]] > Sent: Friday, February 17, 2012 5:34 PM > To: Maes, Richard > Cc: [email protected] > Subject: Re: [gridengine users] Tricky consumables problem > > Am 18.02.2012 um 02:24 schrieb Maes, Richard: > >> To answer your question about layout. All nodes can talk to the > single >> Ixia. There is a diagram below. >> >> To confirm what you are saying here >>> limit pes {ixia1,ixia2,ixia3} to jobs=1 >>> ("jobs" complex setup as a JOB consumable from an arbitrary high > > JOB instead of consumable YES > >> value in the global configuration) >> >> Are you saying I need to create jobs in the cluster configuration -> >> global host? And set it to 999999 for instance? > > Exactly, this way you can limit "jobs" opposed to "slots" in case it's > necessary by RQS for users, pes, queues, hosts. As you used only one > slot in your former setup, I wasn't sure how you would run parallel jobs > then (besides using just a granted node completly for this one-slot job > then). > > -- Reuti > >> ___________ >> [ WA-GRID ] >> [queuemaster] ___________________ >> [wasim01 ] <-NETWORK-> | WA-IXIA-01 | >> [wasim02 ] |slot 1 - ports 1 -4| <-- Eth x 4 --> > DUT >> 1 >> [wasim03 ] |slot 2 - ports 1 -4| <-- Eth x 4 --> > DUT >> 2 >> [wasim04 ] |slot 3 - ports 1 -4| <-- Eth x 4 --> > DUT >> 3 >> [wasim05 ] ____________________ >> [wasim06 ] >> [wasim07 ] >> [wasim08 ] >> ____________ >> >> >> >> >> -----Original Message----- >> From: Reuti [mailto:[email protected]] >> Sent: Friday, February 17, 2012 5:05 PM >> To: Maes, Richard >> Cc: [email protected] >> Subject: Re: [gridengine users] Tricky consumables problem >> >> Hi Richard, >> >> Am 18.02.2012 um 01:28 schrieb Maes, Richard: >> >> I am using gridengine to load tests on to an Ixia. Only one test can >>> run at time so I configured the queue to resource quota configuration >>> with a rule that says limit users * queues lt_np_13 to slots = 1 >> >> as it's for all users, the "users *" can be left out here. >> >> >>> This has worked fine for years. >>> >>> Now, however I have many Ixia blades and I still want to use >> gridengine >>> to distribute jobs to the cluster nodes, but ultimately, there can >> only >>> be one test running per ixia blade. >> >> I don't understand the detailed layout of your cluster. There are >> dedicated nodes connected to each ixia blade? >> >> limit hosts @ixia1 to slots=1 >> limit hosts @ixia2 to slots=1 >> limit hosts @ixia3 to slots=1 >> >> with three hostgroups would do? Or are all nodes connected with IXIA > and >> could use any, but only one as you wrote: >> >> Three PEs with a slot limit of one inside the PE could work, and this >> could be requested by a wildcard: >> >> $ qsub -pe ixia* 1 job.sh >> >> The PE name you get inside the job and can select the proper config >> file. If these are already parallel jobs, this could be put in an RQS >> then: >> >> limit pes {ixia1,ixia2,ixia3} to jobs=1 >> >> ("jobs" complex setup as a JOB consumable from an arbitrary high value >> in the global configuration) >> >> -- Reuti >> >> >>> I think what I need to do is to use a consumable attribute. A > command >>> like qsub -l ixiablade1=1 myjob.sh, will take a consumable resource >> for >>> ixiablade1. >>> However, lets' say I have three ixia blades, ixiablade1, 2 and 3. >>> Somehow I need to have a way of saying you can take ixiablade1 or you >>> can take ixiablade2 or you can take ixiablade3, but you can only take >>> one. Presumably, tests will have to wait until one of the three >>> consumables is available. >>> >>> >>> Here is a diagram >>> >>> [queuemaster] >>> [wasim01] <-----NETWORK -----> IXIA[wa-ixia-01] >>> [wasim02] [slot 1 - ports 1 -4] <-- >>> Direct Ethernet x 4 --> DUT 1 >>> [wasim03] [slot 2 - ports 1 -4] <-- >>> Direct Ethernet x 4 --> DUT 2 >>> [wasim04] [slot 3 - ports 1 -4] <-- >>> Direct Ethernet x 4 --> DUT 3 >>> [wasim05] >>> [wasim06] >>> [wasim07] >>> [wasim08] >>> >>> For example, I may have 100 individual tests queued to run on the >> grid, >>> across 8 different machines, and because of resource quota or >>> consumables, only three jobs can run at a time. When a job moves > from >>> the waiting to running, it will be because one of the consumables was >>> available (and now taken again). When the test begins execution, the >>> test will examine the environment to determine which consumable it > was >>> given and use that to select the appropriate config file (For >> slot1.cfg, >>> slot2.cfg or slot3.cfg) which defines port connections and other DUT >>> related configuration information. >>> >>> Any thoughts would be appreciated. >>> Thanks >>> Rich >>> >>> >>> >>> >>> _______________________________________________ >>> users mailing list >>> [email protected] >>> https://gridengine.org/mailman/listinfo/users >> >> > > _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
