[comp.windows.x] X Terminals vs. Diskless WS

kutz@bgsuvax.UUCP (Kenneth J. Kutz) (12/11/90)

We are in the process of evaluating X capable devices.  Below is a
brief summary of the cost/benefit tradeoffs in comparing alternatives.
At our site, this acquisition is being viewed as an upgrade to a dumb
terminal lab.  Each box represents a "level" of software that we can
choose to pull off of the host system and put into the X display
station.  With each level comes an associated cost.  The four options
(and their associated software levels are):

OPTIONS: (1)          (2)              (3)              (4)
                                                    +-------------+
                                                    | Desktop SW  |
                                   +-------------+  +-------------+
                                   | Window Mgr  |  | Window Mgr  |
                  +-------------+  +-------------+  +-------------+
                  | X Server    |  | X Server    |  | X Server    |
                  +-------------+  +-------------+  +-------------+
INCREMENTAL COST
PER DEVICE OVER
PREVIOUS OPTION:       +$500         +$750-$1000        +$1500

Option (1) is provided by GraphOn, a solution that would not work for
us.  Our host systems will already be in need of upgrades with any of
the remaining options so putting the X Server on the host (and making
sure there is software loaded on each host for this task) is not an
optimal solution.

Option (2) is the typical X Terminal (e.g. NCD 15b, 16, 19b)
configuration.  This option, although better than option (1)
still requires the window manager to run on a host somewhere
presenting the following problems:

   (2a) MULTIPLE POINTS OF FAILURE: if the host running the window
          manager crashes, with it goes your WM capabilities on your
          X terminal.  Recovery from such a crash can be clumsy.

   (2b) WINDOW MANAGEMENT PERFORMANCE DEPENDENT ON HOST PERFORMANCE:
          moving windows around on the screen can become tedious with
          a window manager running on a host already over burdened

   (2c) WM MOUSE EVENTS TRAVEL OVER THE NETWORK RATHER THAN STAYING LOCAL

The marketers have distinguished the device of option 3 as an X Station
rather than an X terminal.  Given option (3) alleviates (2a), (2b), and
(2c), the cost of these benefits may well be worth it.  Recently option
(4) has popped up in our discussions here.  By "Desktop SW" I mean
software which supports a desktop environment similar to the Mac,
OpenWindows (free), X.desktop or Looking Glass.  For the average user,
this environment eliminates the need for having to learn the operating
system commands.

Option (4) then would be a low cost diskless workstation (such as
a Sun SLC) which would run all three levels of software locally
rather than burdening the host with any of those tasks.  This
last option however is radically different from the first 3 for
the following reasons:

  (4a) THE EXECUTABLE IMAGE AND THE DATA ARE NOW ON DIFFERENT MACHINES
       (i.e. all data access is now via NFS).  This is significant
       for commands such as "grep strings.h *.c" in a populated
       source directory.

  (4b) THE DISK HOME FOR THE EXECUTABLE IMAGE AND CPU TO RUN THAT
       IMAGE ARE ON DIFFERENT MACHINES (i.e. typing 'ls' on a diskless
       workstation generates NFS traffic in the form of the 'ls' executable
       traveling to the node which is non-existent in options 1-3)

  (4c) KERBEROS SECURITY PROBLEMS: unencrypted tickets and passwords
       may be paged (and thus available) over the network

  (4d) MULTIPLE POINTS OF FAILURE: losing an NFS server is more serious
       than losing a machine running your window manager as your entire
       display becomes unusable at this point.

Although not mentioned above, option (5) might be option (4) + a local
SCSI disk to eliminate problem (4c) as well as reducing network 
traffic from option (4).

(NOTE: Because this equipment purchase is a replacement for a dumb
 terminal lab, we have purposely left out the obvious benefit of
 local processing availability for options (4) and (5).  It is assumed for
 this acquisition that the computing itself (compilations, editing,
 statistical analysis, etc.) will not be done on the desktop.  The
 only local processing in view here has to do with X, window and
 desktop management, all of which are independent of our user's 
 application)

o What we are interested in is any quantitative or subjective
  studies that have been done on the performance of the entire system
  (from display device to network to host) when one compares option (3)
  with option (4).  

o How much of an impact would an NFS accelerator board
  (such as the one offered by Sun through a third party) have on our
  decision between options (3) and (4)?

o Has anyone successfully implemented option (4) to provide
  their users with a common desktop user interface ACROSS VARIOUS
  OPERATING SYSTEMS for command line functions such as renaming,
  copying, removing, and editing files?

Comments on any or all of these issue would be appreciated.  I will
post a summary of the responses (not merely a concatenation) for those
who are interested.


-- 
  Kenneth J. Kutz		  Internet 	kutz@andy.bgsu.edu         
  Systems Programmer		  BITNET   	KUTZ@ANDY
  University Computer Services    UUCP     	...!osu-cis!bgsuvax!kutz   
  Bowling Green State Univ.       US Mail   238 Math Science, BG OH 43403