drw900@anusf.anu.edu.au ("Drew R Whitehouse") (03/20/91)
I'm interested in hearing peoples (SG people included) experiences using SG's directly from supercomputers via thinks like DGL. How do I go about getting DGL for a new machine (Fujitsu VP 2200 and CM-2) ? What are peoples experiences with faster than ethernet networks for SG's (eg fddi). Thanks, Drew. -- /*---------------------------------------------------------------------------*/ /* Drew Whitehouse, E-mail: drw900@anusf.anu.edu.au */ /* Visualization Programmer, (NOTE: recent change, no more csc2 ) */ /* Australian National University, Phone : (06) 2495985 */ /* Supercomputer Facility. Fax : (06) 2473425 */ /* GPO Box 4, Canberra ACT Australia 2601. */ /*---------------------------------------------------------------------------*/
tttron@escher.lerc.nasa.gov (William Krauss) (03/21/91)
In article <1991Mar20.163153@anusf.anu.edu.au> drw900@anusf.anu.edu.au writes: > > I'm interested in hearing peoples (SG people included) >experiences using SG's directly from supercomputers via thinks like >DGL. How do I go about getting DGL for a new machine (Fujitsu VP 2200 >and CM-2) ? What are peoples experiences with faster than ethernet >networks for SG's (eg fddi). > Thanks, > Drew. > >-- >/*---------------------------------------------------------------------------*/ >/* Drew Whitehouse, E-mail: drw900@anusf.anu.edu.au */ >/* Visualization Programmer, (NOTE: recent change, no more csc2 ) */ >/* Australian National University, Phone : (06) 2495985 */ >/* Supercomputer Facility. Fax : (06) 2473425 */ >/* GPO Box 4, Canberra ACT Australia 2601. */ >/*---------------------------------------------------------------------------*/ Greetings: Ironic that this question should come up now. I'm giving a brief presentation 3/21 on this topic (so I've been summarizing for the past few days anyway). Here at NASA Lewis we've been investigating this (what I term) "How to get there from here." question in a variety of ways. Most of our display devices (the "here" in above term) are SGI machines. Some have high-speed network capabilities ("Ultra Network" to be precise) - all have Ethernet communications. They vary with respect to performance - the ones at my immediate disposal are a 4D/20 GT, 4D/120 GTX*, 4D/340 VGX* (asterisks denote machines with high-speed networking). Note that their UltraNet performance varies accordingly (the 340 has Power Channel for faster communications). When one purchases a site license for the DGL from SGI, one receives the source code. In addition, there are (at least with version 1.1) Makefiles to build the library for "a variety" of "CLIENT" machines. A bit of terminology: DGL terms the CLIENT as the machine where the library ITSELF resides and the HOST as the SGI that will be the display device. The Makefiles include ones for SGI, Convex, Alliant, IBM RS6000 and Sun. Unfortunately, the Makefiles weren't very complete so they needed some "friendly persuasion." The source itself needed a little help in spots too. Thus, once you get the source you can have the "pleasure" (responsibility) of porting to the machine of your choice!!! I am currently using the DGL from a Convex (I have ported to Sun and Alliant too) and I'm working with Cray and SGI on finishing some details on the Cray version. Now, how does it work? It works well. To "convert" a GL (native SGI application) to a DGL (Distributed application) requires 2 additional lines of code in the source file (it's not necessary to "learn" DGL since it's essentially the GL anyway - simple!): - When calling the DGL from C: dglopen(Hostname, ConnectionType); ... GL CODE ... dglclose(serverid); After compiling the application on the CLIENT, one starts the HOST-SGI DGL daemon to "listen" for DGL requests and runs the CLIENT application. I believe >ALL< SGI's are shipped with the DGL daemon, so "installing" the DGL is only necessary on the CLIENT. Performance? Yes. The differences between executing the GL application, the DGL application via Ethernet, and the DGL running over the UltraNet path are significant. Obviously, the native GL application isn't of much interest to this discussion. The Ethernet performance is subjected to the usual traffic (so when there is motion - rotation, etc., there is usually intermittent behavior as opposed to the smooth double-buffered motion of native GL graphics). The UltraNet performance is superb. Since it can handle all of the data being sent from the CLIENT (and then some!) the rotation, etc., is smooth like the native - but slightly slower. This makes sense when you realize that there are other users on the CLIENT competing for precious CPU/swapping/etc. A brief note about UltraNet: it is rated as a Gigabit network (this is between high I/O machines like 2 Crays). The performance from a Cray to say, a VGX, is about 15 Megabits/second - not bad at all. Most of the time, since we have the faster UltraNet route it is the path of choice (no such thing as too fast!). I'm still investigating some other possibilities with the DGL, as well as some other "exploratory" work - but I think this post is long enough already!. Hope this helps. ...perhaps "you >CAN< get there from here"... -William -- >>>> William D. Krauss NASA Lewis Research Center <<<< >>>> Graphics Visualization Lab Cleveland, OH 44135 USA <<<< >>>> tttron@escher.lerc.nasa.gov(128.156.1.94) (216) 433-8720 <<<<
tarolli@westcoast.esd.sgi.com (Gary Tarolli) (03/21/91)
I thought I would shed some light on some of the recent DGL discussions... In article <1991Mar20.193615.2846@eagle.lerc.nasa.gov>, tttron@escher.lerc.nasa.gov (William Krauss) writes: > In article <1991Mar20.163153@anusf.anu.edu.au> drw900@anusf.anu.edu.au writes: > > > > I'm interested in hearing peoples (SG people included) > >experiences using SG's directly from supercomputers via thinks like > >DGL. How do I go about getting DGL for a new machine (Fujitsu VP 2200 > >and CM-2) ? What are peoples experiences with faster than ethernet > >networks for SG's (eg fddi). > > Thanks, > > Drew. > > > > > - When calling the DGL from C: > > dglopen(Hostname, ConnectionType); > ... > GL CODE > ... > dglclose(serverid); > > After compiling the application on the CLIENT, one starts the HOST-SGI DGL > daemon to "listen" for DGL requests and runs the CLIENT application. > I believe >ALL< SGI's are shipped with the DGL daemon,so "installing" the DGL > is only necessary on the CLIENT. > First, although you can call dglopen() and dglclose() you do not HAVE to. Calling dglclose() is nice and certainly good citizenship, but dglclose() is like gexit() - its optional. As for dglclose, you can also omit it. On UNIX machines that support getenv(), the DGL will try to translate some environment variables (similar to what X does for DISPLAY). See the manuals for details. But basically, you can just set one environment variable and the program will work without dglopen(). Unless of course you want to open up windows on multiple graphic servers... Second, starting the DGL daemon (called dgld) on the graphics server involves a one-time change to /usr/etc/inetd.conf. The only installing on the CLIENT is to make sure the service called sgi-dgl is defined (in /etc/services unless you are running YP). > > The Ethernet performance is subjected to the usual traffic (so when there is > motion - rotation, etc., there is usually intermittent behavior as opposed to > the smooth double-buffered motion of native GL graphics). > > The UltraNet performance is superb. Since it can handle all of the data > being sent from the CLIENT (and then some!) the rotation, etc., is smooth like > the native - but slightly slower. This makes sense when you realize that there > are other users on the CLIENT competing for precious CPU/swapping/etc. > Ethernet performance for rotations etc. and real time motion can be quite good if one uses display lists. To achieve 30 frames per second motion based on mouse input requires about 100 packets a second between the client-server. This is not impossible on Ethernet. However, if you attempt to use immediate mode graphics and the DGL, then you will be limited by the bandwidth of the network. The wiser option is to use display lists if possible, when using the DGL. That way the network traffic to redisplay an image can be reduced by orders of magnitude. We (SGI) made sure that display lists were fast and also supported all the new bgn/v/end commands, so that you could take full advantage of all of our new graphics (eg. VGX) and still use display lists. I wrote up a very long and technical chapter regarding DGL performance and how to measure and tune it. See the 4Sight Pgmers Guide, Version 3.0, Chapter 6 and Appendix B for more details. -------------------- Gary Tarolli
tttron@escher.lerc.nasa.gov (William Krauss) (03/22/91)
In article <92563@sgi.sgi.com> tarolli@westcoast.esd.sgi.com (Gary Tarolli) writes: >I thought I would shed some light on some of the recent DGL discussions... > > ...tech stuff deleted... > > >Second, starting the DGL daemon (called dgld) on the graphics server involves >a one-time change to /usr/etc/inetd.conf. The only installing on the >CLIENT is to make sure the service called sgi-dgl is defined (in /etc/services >unless you are running YP). >> Yup, (it's what I do!!). I realize that there ARE a few things that can be omitted, I was NOT implying that I was a DGL guru or anything (I just thought I'd give a general description of what/how it works and my limited experience with it.) We could get into a technical "joust" but I humbly concede. Now, I have access to the EXPERTS (I know where you live!!). > >Ethernet performance for rotations etc. and real time motion can be quite good >if one uses display lists. To achieve 30 frames per second motion based on >mouse input requires about 100 packets a second between the client-server. >This is not impossible on Ethernet. However, if you attempt to use immediate >mode graphics and the DGL, then you will be limited by the bandwidth of >the network. The wiser option is to use display lists if possible, when >using the DGL. That way the network traffic to redisplay an image can >be reduced by orders of magnitude. We (SGI) made sure that display lists >were fast and also supported all the new bgn/v/end commands, so that >you could take full advantage of all of our new graphics (eg. VGX) and still >use display lists. I wrote up a very long and technical chapter regarding >DGL performance and how to measure and tune it. See the 4Sight Pgmers Guide, >Version 3.0, Chapter 6 and Appendix B for more details. > > >-------------------- > Gary Tarolli Thanks for the info! Now I'm an "armed and dangerous DGL warrior!!"i (or should I say thanks for the "light!") -William -- >>>> William D. Krauss NASA Lewis Research Center <<<< >>>> Graphics Visualization Lab Cleveland, OH 44135 USA <<<< >>>> tttron@escher.lerc.nasa.gov(128.156.1.94) (216) 433-8720 <<<<
tarolli@westcoast.esd.sgi.com (Gary Tarolli) (03/22/91)
Although the DGL daemon is shipped on all SGI machines, it is not enabled in /usr/etc/inetd.conf. Thus although your machine has the daemon on it, you still must uncomment out the entry in inetd.conf. The reason for this is that we do not have an "official" port number assigned to the DGL so we did not want to run a daemon that listens to that port. NOTE: this only has to be done on the graphics server, not the graphics client. If you are using DGL a lot, its probably best to enable it on all your IRIS machines. Once the daemon is running, there's nothing else to do, ie. you don't have to rerun the daemon for every application. -------------------- Gary Tarolli