molenda@s1.msi.umn.edu (Jason Molenda) (03/14/91)
I know a new release of NQS will be coming out from SGI some time (soon?) and I would like to post my one humble recommendation that I would kill to see implemented. Any managers of NQS out there probably have grown to hate the qmgr program. It's a nifty program and all, but the ways you input things for queues is (it seems to me at least) erratic. I would kill for a regularlized interface for specifying stuff for queues. A format that I've thought about a bit would be something like --- start of format proposal-type deal ---- set queue <resource name> <queue> [queue,...] = <value> [value,...] There is a good reason for each part of this specification. The "resource name" could come after the list of queue(s), but I think it would probably be easier to parse up front and when you get down to it, it really doesn't matter. The list of queues comes next. Notice that because we are using an equal sign to delimit the value from the queues we can have a list of queues instead of only one queue at a time. This assumes that "=" is not a legal queue name. The equals helps delimit the list of queues and the list of values. The reason the values come last is because it might be a list of users or groups to add to an access list. Therefore it would be difficult to determine the end of the list if it were earlier in the command without some delimination that wasn't a legal user name. End of Line isn't a legal user name, so I figure that should be pretty unique. :) ------ end of format proposal I don't know about other folks, but we are currently tuning our NQS setup quite a bit... I'll get a message like "change the default nice values on all the queues to 15" or somesuch thing and I have 14 queues to change! Yuck. With the new format, I could simply say set queue nice_value i1 i2 i3 i4 i5 i6 i7 m1 m2 m3 m4 m5 m6 m7 = 15 And *taa-daa* it would be done. Wanna add a three new users to the access list of all the "m?" queues? set queue user m1 m2 m3 m4 m5 m6 m7 = larry dick moe Currently there seem to be a billion different formats needed for each different kind of command and I don't see any good reason why this is necessary.. if I'm missing something, please enlighten me. This would make everyone's life easier, I would think. One other thing before I go: Would it be that hard to check the userid in qstat to see if it is root running it to show them the full description of the job running? E.g. a user is running something in queue 'm6'. If I want to find out more information about that job than just that it is running, I have to either be that user or use qmgr as an 'Manager'. Couldn't qstat check t osee if a 'manager' (or at least root) was running it and display the full information? Or doesn't it _have_ the full information? i obviously don't know much about the internal details of the program... -- Jason Molenda, Tech Support, Iris & News Admin, Minnesota Supercomputer Inst molenda@msi.umn.edu || "You can tune a piano but you can't tuna fish."
torda@igc.ethz.ch (Andrew Torda ) (03/14/91)
In article <1991Mar14.073500.11533@s1.msi.umn.edu>, molenda@s1.msi.umn.edu (Jason Molenda) writes: > I know a new release of NQS will be coming out from SGI some time (soon?) > and I would like to post my one humble recommendation that I would > kill to see implemented. I am sorry to start whinging again, but seeing anyone mention sgi's nqs makes me angry. Have you used nqs on a convex ? cray ? They can talk to each other. We have nqs from Sterling software on our suns. It also talks to nqs on the convex and cray (no problems submitting jobs remotely, querying remote queues etc...) Now, which is the one port of nqs which does not talk to any other ? SGI. Repeatededly querying SGI about this, nobody has explained what performance or extra functions brought about this networking incompatibility. Thus, if the incompatibility is not necessary or useful, it falls into the category of totally gratuitous incompatibility. I appreciate that this complaint of mine is not the same as the original posting about the syntax for qmgr, but the current SGI product has more serious problems than merely clumsy syntax (which is at least common across the different platforms that one might have to manage). Also, bear in mind that IBM will be releasing an official port of nqs to their wonder workstations, so this can be added to the list of machines which SGI's nqs can not talk to. -- Andrew Torda, ETH, Zurich
bh@sgi.com (Bent Hagemark) (03/15/91)
In article <1991Mar14.073500.11533@s1.msi.umn.edu> molenda@s1.msi.umn.edu (Jason Molenda) writes: >I know a new release of NQS will be coming out from SGI some time (soon?) >and I would like to post my one humble recommendation that I would >kill to see implemented. > >Any managers of NQS out there probably have grown to hate the qmgr >program. It's a nifty program and all, but the ways you input things >for queues is (it seems to me at least) erratic. I would kill for >a regularlized interface for specifying stuff for queues. A format >that I've thought about a bit would be something like >... >Jason Molenda, Tech Support, Iris & News Admin, Minnesota Supercomputer Inst >molenda@msi.umn.edu || "You can tune a piano but you can't tuna fish." Thanks much for your detailed proposal! The engineering of the next release of NQS is done and includes no significant changes to qmgr. Personally, I don't have much fondness for qmgr, either! I'd rather see an ascii file (ala,/etc/printcap) which you can edit directly or front-end with (better) qmgr commands or even a GUI. Also, text files are easily turned into YP maps. BUT! I'm in position to promise any of this. However, we do want to hear what people like and don't like. This latest release of NQS was engineered with a fair amount of customer feedback. Bent
torda@igc.ethz.ch (Andrew Torda ) (03/16/91)
In article <1991Mar14.221446.14293@odin.corp.sgi.com>, bh@sgi.com (Bent Hagemark) writes: > Personally, I don't have much fondness for qmgr, either! I'd rather > see an ascii file (ala,/etc/printcap) which you can edit directly or > front-end with (better) qmgr commands or even a GUI. Also, text files are What if you have a big server with no graphics ? One should not rely on a GUI. This is not an unlikely machine to be running nqs. Also, note that nqs qmgr does read from the standard input. This does give you some scope to construct an ascii file as you suggest. In order to manage a number of machines here (13 of them running nqs), we already keep one ascii file with all the definitions of queues. We then have a script like foreach nqs_machine (`cat machine_list`) rsh $nqs_machine qmgr < queue_description_file end although I appreciate this is not as neat as a file analogous to /etc/printcap. > However, we do want to hear what people like and don't like. This latest > release of NQS was engineered with a fair amount of customer feedback. Does the new nqs maintain SGI's incompatibility with respect to nqs running on other machines ? -- Andrew Torda, ETH, Zurich
zrfa0390@awsws4.rus.uni-stuttgart.de (U. Lang) (03/20/91)
In article <1991Mar15.174247@igc.ethz.ch> torda@igc.ethz.ch (Andrew Torda ) writes: > >Does the new nqs maintain SGI's incompatibility with respect to nqs >running on other machines ? > >-- >Andrew Torda, ETH, Zurich We would also like to see nqs on SGI's being compatible with CRAY, CONVEX, IBM, etc. Currently we are not able to submit batch jobs from the SGI's to our CRAY, Convex or IBM. We have ported the NQS version from Cosmic on the IBM. We would prefer to use the SGI version of NQS on our Irises instead of porting the Cosmic version on the Irises. Ulrich Lang, University of Stuttgart Computer Center M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M n n n n n n n p M n Ulrich Lang, University of Stuttgart Computer center
doelz@urz.unibas.ch (03/22/91)
In article <1991Mar20.112324.17045@rusmv1.rus.uni-stuttgart.de>, zrfa0390@awsws4.rus.uni-stuttgart.de (U. Lang) writes: > In article <1991Mar15.174247@igc.ethz.ch> torda@igc.ethz.ch (Andrew Torda ) writes: >> >>Does the new nqs maintain SGI's incompatibility with respect to nqs >>running on other machines ? >> >>-- >>Andrew Torda, ETH, Zurich > > We would also like to see nqs on SGI's being compatible with CRAY, CONVEX, > IBM, etc. Currently we are not able to submit batch jobs from the SGI's > to our CRAY, Convex or IBM. We have ported the NQS version from Cosmic > on the IBM. We would prefer to use the SGI version of NQS on our Irises > instead of porting the Cosmic version on the Irises. > > Ulrich Lang, University of Stuttgart Computer Center > There is a 'original' available from Sterling which also communicates with the rest of the NQS' implementations. We need to run NQS on more than SGI's, therefore, would *really* like to see the qmapmgr on SDGI's NQS. Otherwise we might be tempted to move to the competitor's product. Regards Reinhard ************************************************************************ Dr. Reinhard Doelz * EAN doelz@urz.unibas.ch Biocomputing * DECNET 48130::doelz Biozentrum der Universitaet * X25 psi%46211142::embnet Klingelbergstrasse 70 * FAX x41 61 256760 CH 4056 Basel * TEL x41 61 253880 ext 888 ************************************************************************
torda@igc.ethz.ch (Andrew Torda ) (03/22/91)
In article <1991Mar22.103255.1460@urz.unibas.ch>, doelz@urz.unibas.ch writes: [...] > There is a 'original' available from Sterling which also communicates with the > rest of the NQS' implementations. We need to run NQS on more than SGI's, > therefore, would *really* like to see the qmapmgr on SDGI's NQS. Otherwise > we might be tempted to move to the competitor's product. We did. It works and allows us to move jobs between the various machines. Basically, we are happy, but if you want non-degrading process priorities, you have to find the line in the nqs code which spawns off your job, or invoke the nqs daemon from a line like npri -h xx nqsdaemon. This is a small inconvenience to allow a Network Queue System (nqs) to work over a network. Sorry I sound so bitchy about this product. -- Andrew Torda, ETH, Zurich