Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!gatech!usenet.ins.cwru.edu!eagle!escher!tttron
From: tttron@escher.lerc.nasa.gov (William Krauss)
Newsgroups: comp.sys.sgi
Subject: Re: supercomputers, DGL, FDDI (longish)
Message-ID: <1991Mar20.193615.2846@eagle.lerc.nasa.gov>
Date: 20 Mar 91 19:36:15 GMT
References: <1991Mar20.163153@anusf.anu.edu.au>
Sender: news@eagle.lerc.nasa.gov
Reply-To: tttron@escher.UUCP (William Krauss)
Organization: NASA/Lewis Research Center, Cleveland
Lines: 106

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  <<<<