dfr@CAD.USNA.MIL ("David F. Rogers") (05/14/89)
Since you asked, I would prefer NOT to have a window system! I resent having to use one on the 4d. I hate giving up those cycles. Don't say the window manager, any window manager, does not absorb significant cycles. They all do. I recently demonstrated how much by running exactly the same B-spline Surface Ship Design program on both a 2400T and a 4D/20 side by side. The 4D/20 has roughtly 10 times the cpu power and 3-5 times the screen i/o as the 2400T, at least according to the specs. The 4D/20 ran VISUALLY slower! The more windows you put up the slower it ran. If I didn't need the cpu cycles for associated analysis programs, I would go back the the 3000 series. Sigh ...... Dave Rogers
msc@ramoth.SGI.COM (Mark Callow) (05/14/89)
In article <8905131724.aa08908@CAD.USNA.MIL>, dfr@CAD.USNA.MIL ("David F. Rogers") writes: > Since you asked, I would prefer NOT to have a window system! I resent having to > use one on the 4d. I hate giving up those cycles. Don't say the window manager, > any window manager, does not absorb significant cycles. They all do. > I recently demonstrated how much by running exactly the same B-spline > Surface Ship Design program on both a 2400T and a 4D/20 side by side. The > 4D/20 has roughtly 10 times the cpu power and 3-5 times the screen i/o as > the 2400T, at least according to the specs. The 4D/20 ran VISUALLY slower! > The more windows you put up the slower it ran. If I didn't need the cpu > cycles for associated analysis programs, I would go back the the 3000 series. > Sigh ...... If you put up more windows doing drawing, the system has to do more work so of course a given application is going to slow down. Many people like to run more than one thing at a time and regard being able to do so as an great advantage. 4Sight has 2 potential impacts on performance: memory and input overhead. The news server in 4Sight uses around 2 megabytes of memory. This definitely causes increased swapping on 8 megabyte systems. Since many input events are routed through the window server, running the window system adds some overhead to event delivery. We have been working on both these issues for release 3.2. Input overhead (total system + user cycles) will be not more than 5% of the cpu. Working set of the window server will stay below 1.5 megabytes. 4Sight does not introduce any overhead on drawing. All drawing goes directly from the GL program to the hardware just as if the window system wasn't there. -- -Mark
dfr@CAD.USNA.MIL ("David F. Rogers") (05/14/89)
G'day, Mark Callow says they are working on the window performance issue for release 3.2. He has really missed the point. I want the option of having NO window manager. Dave
blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates TAD/TAB ms294 x42854") (05/15/89)
Do you HAVE to use the window manager on the 4D's? On the 3000's you don't have to have it running. We have a few programs that require MEX not be running. I hear 4Sight requires 4.5Mb to run, which doesn't give you any memory left to run applications on an 8Mb system. Which is the base line system SGI sends you. David Rogers how much memory do you have? If it is only 8Mb, then that is probably why things run so slowly. Try adding at LEAST another 4Mb, better yet fill the machine. That SHOULD give you a dramatic improvement, so I have been told. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov
timelord@eos.UUCP (G. Murdock Helms) (05/16/89)
("David F. Rogers") writes: >Mark Callow says they are working on the window performance issue for >release 3.2. He has really missed the point. I want the option of having >NO window manager. How about a window manager that has a toggle on it so you can turn it on if you want it, and off if you don't? Most of the time the programs we run on our GTX require windowing, but sometimes they don't, and the toggle mechanism might be beneficial to a lot of folks using Irises. Same thing goes for GTX dog...a toggle for shading/no shading on the planes, and maybe some mechanism to only broadcast dog packets to identified Irises? Our network administrator goes wild when we try to dogfight after work and gets VERY unhappy with us! If the demo development people have a little time on their hands, please send me email...there's this great demo that would look really great on an Iris.... -Murdock timelord@eos.arc.nasa.gov
kvancamp@PICA.ARMY.MIL (Ken Van Camp) (05/16/89)
>Mark Callow says they are working on the window performance issue for >release 3.2. He has really missed the point. I want the option of having >NO window manager. Yeah, what he said! On the 3000's you could at least do a reasonable amount of text operations without Mex running, but on the 4D's the only option you have is NOGRAPHICS=1 when you login. Then your visual editors don't work. I guess that's why SGI moved vi from /bin to /usr/bin on the 4D's; you can't use it anyway without your window manager running. Some times I'd like to just login for text operations, and then I don't want to have to wait for 4Sight to start up. Bad design, SGI! --Ken Van Camp ARPANET: kvancamp@PICA.ARMY.MIL -or- kvancamp@ARDEC.ARPA BITNET: (use above through normal gateways, like UBVM.CC.BUFFALO.EDU) USENET: pica.army.mil!kvancamp@UUNET.UU.NET UUCP: ...!{uunet,rutgers}!pica.army.mil!kvancamp "Tis better to Send than to Receive."
JORDAN@gmr.COM (05/16/89)
I'm not sure what the user really wants, but I would like to have the option of turning windows off, but still have graphics capability. For my application (real-time graphical simulation) I do not need windows!! (Although, they do come in handy when I need to "vi" 4 files simultaneously). From what I understand, I cannot do graphics unless the window manager is running. If anyone knows of a workaround, I'd be glad to listen. t. p. mugabi-jordan gm systems engineering 313-280-6766 troy, michigan
wiltse@oceana.SGI.COM (Wiltse Carpenter) (05/16/89)
In article <8905151354.aa11297@ARDEC-AC4.ARDEC.ARPA>, kvancamp@PICA.ARMY.MIL (Ken Van Camp) writes: > Then your visual > editors don't work. I guess that's why SGI moved vi from /bin to /usr/bin > on the 4D's; you can't use it anyway without your window manager running. > > Some times I'd like to just login for text operations, and then I don't > want to have to wait for 4Sight to start up. Bad design, SGI! > On the Personal Iris it is possible to use vi without 4Sight. If one logs using the NOGRAPHICS flag (type NOGRAPHICS=1 after your login id), then set the TERM environment variable to "iris-tp", vi should work. It may be necessary to also set the environment variable LINES to 40 (oops!). For instance: $ TERM=iris-tp $ LINES=40 $ export LINES TERM or % setenv TERM iris-tp % setenv LINES 40 Again, this only works on the Personal Iris (4D/20). Here are some other PI tricks: You can set the colors that are used by the textport (the mode you get when you login with NOGRAPHICS). Get into "Manual Mode" from the prom menu and type: setenv screencolor 6f6f6f setenv pagecolor f0f0f0 setenv logocolor 000000 The three variables take a 6 hex-digit rgb value for the screen background, text background and logo color (The logo comes up if console is set to G). They're retained in nvram too! If Something Bad happens and you need to bring up the system in single user mode, get into manual mode and set the environment variable "initstate" to "s": setenv initstate s and then type "auto". This is a one-shot deal and isn't saved in nvram. -Wiltse Carpenter
phil@BRL.MIL (Phil Dykstra) (05/16/89)
Dave Rogers writes: "I want the option of having NO window manager." I second (third?) this. In this era of distributed processing and remote graphics we use SGI's here remotely all the time. The Crays, or minis can rsh graphics display programs or use remote image display tools. In most of these cases you want to devote the entire machine and display to that one application. It is ridiculous to have to log into the console to use the graphics. As a hack, SGI told us how to startup up a skeleton 4Sight system if none was running, but that requires modifying all of your applications to do this, and alas is not yet binary compatible across the 4D line. I miss the Mexless 3030 and the Maxless 4D that never was. We are probably stuck with window based graphics, but if I may paraphrase (from memory) Andy van Dam a couple of months ago "Touting windowing systems on graphics workstations is making a virtue out of a necessity." - Phil
blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates TAD/TAB ms294 x42854") (05/16/89)
I second that dog note. Broadcast dog packets only to identified IRIS's. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov
blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates TAD/TAB ms294 x42854") (05/16/89)
Phil Dydstra makes sense on all but one sentence. "It is ridiculous to have to log into the console to use the graphics." I find the sentence ridiculous. The IRISes are so fast because you use the console. Doing graphics with a dumb graphics terminal would slow things down substantialy. Maybe he didn't say what he meant? -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov
thant@horus.SGI.COM (Thant Tessman) (05/16/89)
In article <8905151827.aa08875@SMOKE.BRL.MIL>, JORDAN@gmr.COM writes: > I'm not sure what the user really wants, but I would like to have the option > of turning windows off, but still have graphics capability. For my > application (real-time graphical simulation) I do not need windows!! > (Although, they do come in handy when I need to "vi" 4 files simultaneously). > > From what I understand, I cannot do graphics unless the window manager is > running. If anyone knows of a workaround, I'd be glad to listen. > > t. p. mugabi-jordan > gm systems engineering > 313-280-6766 > troy, michigan I'm not sure I understand the problem. Why can't the application that doesn't need the window manager just use ginit() and pretend the window manager isn't there? As I understand it, the window manager doesn't steal any cpu cycles unless the mouse is moving, and even then it doesn't use (eventually won't use?) more than 5%(?). Is it the amount of memory it uses? How does stuff about when to swap stuff out get decided? The only other thing I can think of is that other people can run windows on top of the thing that thinks there isn't a window manager. Is there a way to lock other windows out? thant@sgi.com "disclaim"
blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates TAD/TAB ms294 x42854") (05/17/89)
These people don't want all the extra overhead of the window manager, which is not a small amount in both memory usage and cpu time. I was told by a sales rep. that 4Sight uses 4.5Mb. That is not small. And if you have to swap out to disk a lot that is going to slow things down a lot. Like I said before does 4Sight HAVE to be running. Mex on the 3000's doesn't HAVE to be running to use graphics. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov
msc@ramoth.SGI.COM (Mark Callow) (05/17/89)
In article <3620@eos.UUCP>, timelord@eos.UUCP (G. Murdock Helms) writes: > ("David F. Rogers") writes: > >Mark Callow says they are working on the window performance issue for > >release 3.2. He has really missed the point. I want the option of having > >NO window manager. > I didn't miss the point. We are probably even going to document how to travel on the bare metal. But it isn't easy. The window *system* provides a lot of support that people tend to take for granted not realising that it is provided by the window system. > How about a window manager that has a toggle on it so you can turn it on if > you want it, and off if you don't? Most of the time the programs we > run on our GTX require windowing, but sometimes they don't, and the > toggle mechanism might be beneficial to a lot of folks using Irises. Our preferred approach is to gracefully make the power of window system available as you use it. The counterpoint to that is if you don't use it, it doesn't get in the way. Think of this as an automatic switch. If you create a full screen window (e.g. through ginit) then the window system is out of the way except for keyboard translation (if you are using the keyboard), menu service (if you are using menus) and helping deliver mouse and keyboard events. If the window system didn't do this latter task, some other process would have to perform the same work. The only resource the window system is consuming in this state is swap space. Now if the user of your program decides he wants to also run another application he can simply start it up and the window system will gracefully come into play without any abrupt change from one state to another. Yes the 3000 could run without Mex. But could it run without a window system? Not really. Pieces of the window system were in the kernel and are used by all clients even when Mex wasn't running. For example, those primitive windows called textports. Without those textport windows almost all the programs that run without mex would be useless. We still see a lot of programs that are dependent on textports. As I said up front, travelling on the bare metal isn't easy. -- -Mark
thant@horus.sgi.com (05/17/89)
Howdy, Yeah, the window manager uses a good hunk of cpu when you're using it (crossing window boundaries, moving windows around, context switching, etc.), but if there is only one window the size of the screen the only thing the window manager would have to do is check the mouse position against a (very short) window segment list. I've got a feeling that in this condition the window manager uses even less than 5% of the cpu. 4.5 meg of window manager would be a real pain on a minimal system. But if there was only one window the size of the screen I would think that the window manager would get mostly swapped out and not swapped back in because nothing could happen if no window borders were crossed. This is the stuff that is black magic to me, but I wonder if people have tried this just to check. To tell you the truth, i think there are people working on a minimalist window manager. I think it's a bad idea. Yeah, you didn't have to run mex on the 3000, but the fact that some of the stuff ran with the window manager and some of the stuff didn't was an endless source of headaches for SGI and customers. I think the answer is to make the window manager as painless as possible by increasing its performance and decreasing its size. One thing they are working on is getting it to use the shared GL. This will decrease its size a lot. thant@sgi.com P.S. I'm not a part of the window manager group so I obviously am not speaking for them.
moss@BRL.MIL ("Gary S. Moss", VLD/VMB) (05/17/89)
< Phil Dydstra [Dykstra] makes sense on all but one sentence. "It is ridiculous to < have to log into the console to use the graphics." I find the sentence < ridiculous. The IRISes are so fast because you use the console. Doing < graphics with a dumb graphics terminal would slow things down substantial[l]y. < Maybe he didn't say what he meant? It made perfect sense to me; you 'rlogin' from a terminal or a window on your Sun workstation which has a *decent* keyboard for those of us that learned to type correctly (i.e. don't stare at the keyboard), and use the IRIS to display graphics. If you don't think that we can type faster on a Sun, DEC, AT&T, Visual, etc. keyboard than on an IRIS, then you probably either look at the keyboard when you type or learned on an IRIS. [Remapping the keys only helps for the Esc, Ctrl and Caps Lock; it still leaves ~,`,|,\, Backspace, and Delete to name a few all *screwed* up because the layout and shape of the keys prohibits doing a complete fix.] [My guess is that the 4d keyboard sells more Suns than Sun Ads.] The other *big* reason for not using the console, is that 4Sight does not allow you to direct the input focus to a window other than the one under the cursor. This has broken all of my applications that manipulate the graphics cursor from keyboard commands typed in a text window *and* there is no work-around other than using 'rlogin' from another workstation/terminal. I much prefer 4Sight to Mex (in general), but problems as fundamental as these tend to alienate the developer types. -moss
phil@BRL.MIL (Phil Dykstra) (05/17/89)
Perhaps I didn't say what I should have, so one last point before I shut up: If we have to run graphics programs under MAX, fine, but I wish then that SGI could figure out how to make MAX *always* available. That is, I object to MAX starting and stopping based on someone logging into the physical console. There shouldn't have to be *anyone* logged in to use the graphics. You should be able to rexec/rsh graphics programs. The mechanism/services of the window system shouldn't be tied to a particular user ID. There are security issues to tackle with this, but I wish the presence of MAX wasn't tied to someone logging in/out of the console. Has anyone at SGI thought of a way to implement this? - Phil
blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates TAD/TAB ms294 x42854") (05/17/89)
Oh! I see now. The impression I had was he was trying to display
graphics on a remote terminal. I stand corrected on that one.
I have been told that you CAN direct the input focus to a window OTHER
than the one under the cursor, the person who told me, however, has never
tried it and he doesn't care to either. I can see reasons to do it both
ways. I have some aplications that I NEED to fix input focus even though
the cursor is over a different window. Other times the other way would be
nice.
--
Brent L. Bates
NASA-Langley Research Center
M.S. 294
Hampton, Virginia 23665-5225
(804) 864-2854
E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.govblbates@AERO4.LARC.NASA.GOV ("Brent L. Bates TAD/TAB ms294 x42854") (05/17/89)
One thing I HATE about MEX on a 3130, is that it dies VERY VERY EASILY. (It isn't that difficult to crash a 3130 in the first place, but MEX is even easier). I haven't use the 4D's much, but I hope the software is written better than the 3000's version. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov
moss@BRL.MIL ("Gary S. Moss", VLD/VMB) (05/17/89)
< I have been told that you CAN direct the input focus to a window OTHER < than the one under the cursor Well, the GL routine 'winattach' no longer does anything, so are you talking about writing PostScript code or what? -moss
blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates TAD/TAB ms294 x42854") (05/17/89)
I think he said you had to make changes in some 4Sight start up files, . files in the users home directory. The problem is that it takes effect for the entire login period, I think. That is as specific as I can get at the moment. I would have to ask him again to get more specific information. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov
dfr@CAD.USNA.MIL ("David F. Rogers") (05/17/89)
G'day Mark, I may even antedate you with SGI. As I recall the first 2400 that I bought did not have a window manager at all, i.e., no mex. Since I have raised the question, what does not someone at SGI sit down and provide a concise, definitive answer to: 1. how much memory does the current window manager system use -- say with one window. How much additional memory for each additional window? 2. How much cpu power does the window manager absorb -- say with one window. How much for each additional window or task, e.g. mouse input, keyboard input, etc. 3. How can you absolutely minimize the effect of the window manager? The thing that really concerns me here is that I demonstrated that the new machine was not VISUALLY as fast as a 2400T. In real time interactive systems it is VISUALLY that counts. Professor David F. Rogers Aerospace Engineering Department U.S. Naval Academy Annapolis, MD 21402 USA Tel: 301-267-3283/4/5 ARPANET: dfr@usna.navy.mil UUCP: ~uunet!usna!dfr
moss@BRL.MIL ("Gary S. Moss", VLD/VMB) (05/17/89)
Well, changing the behavior of 4Sight with user.ps files or NeWS/* files off of the users home directory will not fix the problem, since an application must work regardless of the user's environment. -moss
goss@SNOW-WHITE.MERIT-TECH.COM (Mike Goss) (05/17/89)
Regarding the message from phil@BRL.MIL: > ... > > That is, I object to MAX starting and stopping based on someone logging > into the physical console. There shouldn't have to be *anyone* logged in > to use the graphics. You should be able to rexec/rsh graphics programs. > The mechanism/services of the window system shouldn't be tied to a > particular user ID. > > There are security issues to tackle with this, but I wish the presence > of MAX wasn't tied to someone logging in/out of the console. Has anyone > at SGI thought of a way to implement this? > > - Phil There is a way to run graphics programs on the 4D under release 3.1 without logging in at the console (for example, from another terminal): 1) Execute the command "/etc/gl/restartgl". This will start the window manager at the console, running as your user ID (make sure you logout or kill the window manager when you're done). You will need to wait a few seconds for it to load, as you would if you had logged in at the console itself. 2) Run your graphics programs. 3) When done, you can get rid of the window manager doing a "ps -ef" command to find process "/etc/gl/grcond", and then killing that process (or you can logout at the console itself). I've tried this on a 4D/60T, but it will probably work on any IRIS running software release 3.1. It's not the most convenient procedure in the world, but it will let you do what you want to do. Mike Goss, Merit Technology Inc.
blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates TAD/TAB ms294 x42854") (05/18/89)
NFS is running on a couple of machines here, but I don't think it is working 100% (or even 90%). One thing you HAVE to have before even trying to use NFS is OS 3.6. NFS does not work with 3.5 or lower. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov
ciemo@bananapc.wpd.sgi.com.SGI.COM (Dave Ciemiewicz) (05/18/89)
In article <8905171545.AA00615@snow-white.merit-tech.com>, goss@SNOW-WHITE.MERIT-TECH.COM (Mike Goss) writes: > > 3) When done, you can get rid of the window manager doing a > "ps -ef" command to find process "/etc/gl/grcond", and > then killing that process (or you can logout at the console > itself). > > Mike Goss, Merit Technology Inc. The command /etc/killall will allow you to kill a program by specifying its name. The command "/etc/killall grcond" should do the trick. If killall complains about permissions, you may have an older release. Use "chmod 2111 killall" to set permissions on killall so any user can use it on their processes. For more details on /etc/killall, see the manual page in section 1M. -- Dave (commonplace) "Boldly going where no one cares to go." Ciemiewicz (incomprehensible) ciemo (infamous)
tarolli (Gary Tarolli) (05/18/89)
There can be multiple reasons why a 4D machine is VISUALLY slower than a 2400T. One could be that the window manager is slowing things down, either thru consuming CPU cylces or enough memory to cause extra paging. Another could be because the 4D is performing "extra" unnecessary graphics, in other words the port of the code created inefficiencies. A classic example is that the 4D machines smooth shade all polygons by default, ie shademodel(GOURAUD) is the default. This was for compatability sake. If you are drawing flat polygons and forget to turn shademodel(FLAT) on, performance is adversly effected. Things like flight can run 5-10 times slower. There are other graphics routines that are slower on a 4D than on a 2400T. These are routines like depthcue() that are not usually called often enough to matter, but once in a while you run across an application that calls it excessively. Because it was fast on a 2400T, no on cared, but on the 4D it does a system call so...... The old curve demo had this problem at first. So, I am not convinced that the window manager is really making your 4D visually slower than a 2400T. When you are not paging, the window manager has very little overhead and generally stays out of the way when you are doing fast 3D graphics. I would place my bets that your user code is not doing what you expect on the 4D or is calling a routine that got slower. Use prof/pixie to detect these.
timelord@eos.UUCP (G. Murdock Helms) (05/18/89)
("Brent L. Bates TAD/TAB ms294 x42854") writes: > > NFS is running on a couple of machines here, but I don't think >it is working 100% (or even 90%). One thing you HAVE to have before >even trying to use NFS is OS 3.6. NFS does not work with 3.5 or lower. We're running NFS on our Irises...our 2400Turbo is the fileserver for both a 3130 and a 4DGTX, and we've been pretty happy with it so far. I'm planning to try turning the GTX into an NFS server for our Personal Iris next. The only problem we've had (and this is important): I like to run all my backups at the same time. Saves time. At any rate, don't forget to dismount shared directories/filesystems from the client BEFORE you bring the server down for backups. Otherwise, your server will happily run backups while the client twiddles its thumbs for the next half hour while it tries to figure out what's going on. At the first mention of a shared filesystem, it goes off into neverneverland, and the old "ctrl backslash" trick doesn't seem to work on the GTX. -Murdock
dfr@CAD.USNA.MIL ("David F. Rogers") (05/18/89)
Sorry Garry, the application in question is strickly wire-frame. Dave Rogers
pwolfe@kailand.kai.com (Patrick Wolfe) (05/18/89)
> /* Written by timelord@eos.arc.nasa.gov */ > At any rate, > don't forget to dismount shared directories/filesystems from the client > BEFORE you bring the server down for backups. Otherwise, your server > will happily run backups while the client twiddles its thumbs for the > next half hour while it tries to figure out what's going on. At the first > mention of a shared filesystem, it goes off into neverneverland, and the > old "ctrl backslash" trick doesn't seem to work on the GTX. This is because you "hard mount" your NFS filesystems. We "soft mount" all of our filesystems, which has the effect of timing out instead of hanging when you mention a shared filesystem. Of course, it's still preferable to dismount filesystems when you *know* they are going to be unavailable.
meyer@unizh.UUCP (Urs Meyer) (05/22/89)
In article <8905171545.AA00615@snow-white.merit-tech.com> goss@SNOW-WHITE.MERIT-TECH.COM.UUCP writes: > >There is a way to run graphics programs on the 4D under release 3.1 >without logging in at the console (for example, from another terminal): > > 1) Execute the command "/etc/gl/restartgl". This will start > the window manager at the console, running as your user ID > (make sure you logout or kill the window manager when > you're done). You will need to wait a few seconds for > it to load, as you would if you had logged in at the > console itself. > > 2) Run your graphics programs. > > 3) When done, you can get rid of the window manager doing a > "ps -ef" command to find process "/etc/gl/grcond", and > then killing that process (or you can logout at the console > itself). > >I've tried this on a 4D/60T, but it will probably work on any IRIS >running software release 3.1. It's not the most convenient procedure >in the world, but it will let you do what you want to do. > >Mike Goss, Merit Technology Inc. Be careful to delete every process you'd created. There is at least a wsh and csh hanging around. The following shell script works on 3.1C and did work on 3.0D, as well as on a 4D/20G and 4D/70GT: /etc/gl/grcond & sleep 60 grcpid=`ps -fu $LOGNAME |grep '/etc/gl/grcond' |grep -v grep |awk '{print $2}'` wshpid=`ps -fu $LOGNAME |grep 'wsh.*grconc' |grep -v grep |awk '{print $2}'` cshpid=`ps -fu $LOGNAME |grep $wshpid |grep csh |grep -v grep |awk '{print $2}'` your program sleep 5 kill -9 $cshpid # killing the csh will also get rid of the wsh sleep 5 kill $grcpid # no kill -9 here finding the right process id's is not very elegant but it works. --- Urs Meyer meyer@ifi.unizh.ch [ @relay.cs.net ] University of Zurich, {uunet,...}!mcvax!cernvax!unizh!meyer Dept. of Computer Science, K114930@CZHRZU1A.BITNET CH-8057 Zurich