Conference bulova::decw_jan-89_to_nov-90

281.0. "DECwindows Performance - Sales Update Article" by POOL::HENDERSON (Knowledge Is Power) Thu Feb 23 1989 09:43

VMS DECWINDOWS PERFORMANCE
  
  
The purpose of this article is to present an overview of some of the key
performance characteristics of VMS DECwindows. It is oriented toward system
configuration issues rather than toward measurements and timings of graphics
and user interface primitive operations. Using a question-and-answer format,
it will help you to understand the performance differences between workstations
with different CPU's and different memory configurations.
  
  
WHAT IS DECWINDOWS?
  
DECwindows is Digital's new computing environment based on the industry
standard X Window System (tm) developed at MIT by several vendors including
Digital. DECwindows provides software developers with the ability to develop
and run distributed graphical applications in a heterogenous network
environment. This is accomplished by implementing the server-client model
defined by the X standard. In addition to providing a programming environment
for building applications, the DECwindows product includes a number of
so-called "out of the box" applications.
  
This article assumes that the reader has read the "Overview of VMS DECwindows".
  
  
HOW DOES THE PERFORMANCE OF VMS DECWINDOWS COMPARE TO THAT OF THE MIT VERSION?
  
The DECwindows server has implemented many performance improvements over
the standard X system available from MIT. Comparisons were done between
a field test version of VMS DECwindows and the MIT X11 (Release 2) software.
It showed significant improvements in the VMS version in almost all important
graphics and windowing primitives.
  
  
HOW DO THE VMS AND ULTRIX VERSIONS COMPARE?
  
Best case user-interface performance of DECwindows is very similar on
Ultrix and VMS, when run on identical hardware platforms. This conclusion
is based on data gathered on a recent DECwindows field test version. However,
this does not include page-faulting activity, disk I/O, and other operating
system-specific activities, which will impact user perceptions of performance.
  
  
HOW IMPORTANT IS MEMORY TO VMS DECWINDOWS PERFORMANCE?
  
Memory is the most significant hardware resource in a VMS DECwindows
workstation. With sufficient memory, applications will perform reasonably
with either a VAXstation-2000 class machine or a VAXstation-3000 class
machine. But with insufficient memory, application performance can become
unacceptable on either type of machine.
  
The vast flexibility and common "look and feel" of the DECwindows user
interface comes at a price -- it costs memory. For example, VMS DECwindows
has a richer user interface than VWS (UIS), but it requires more memory to
achieve comparable performance. DECwindows is built upon the X server-client
model and the X toolkit programming interface. This object-oriented design
is inherently expensive in its memory consumption, particularly for dynamic
data structures. These structures contain the data necessary to represent
objects and their characteristics. In DECwindows, these objects are "widgets"
and windows. The more capabilities an application has, the more widgets and
windows it is likely to use, and, hence, the more memory it will require.
Even in spite of significant engineering effort to conserve memory, its
utilization by DECwindows applications remains high.
  
The table below shows that the 4-megabyte (MB) configuration and the 6 MB
configuration are bare minimums for non-clustered and clustered operation,
respectively. These systems are supported but not recommended. Since many
of our VAXstation-2000 customers now own such systems, it is important to
understand how to make the best use of the limited memory they have available.
The best technique for dealing with this problem is to take advantage of the
DECwindows capability which allows applications to be run remotely. When an
application is run in this mode, most of its memory requirement is satisfied
on a remote network node. This is discussed in more detail later in this
article.
  

  
MEMORY CONFIGURATION GUIDELINES
  
Use the following table as a guideline to determine which memory configurations
to recommend.
  
  
  
                  DECwindows Memory Configurations
  
  
Memory          Standalone      Network (DECnet)        VAXcluster
------          ----------      ----------------        ----------
  
  
  
4 MB            Supported       Supported               Not Supported
                                (Remote Apps Only)
  
  
6 MB            Minimum         Minimum                 Supported
                Recommended     Recommended             
                                                          
  
8 MB            Recommended +   Recommended +           Minimum
                                                        Recommended
  
  
10 MB           Recommended ++  Recommended ++          Recommended +
  
  
  
-------------------------------------------------------------------------------
  
Legend:
  
NOT SUPPORTED -- This configuration of memory and software is not supported.
  
SUPPORTED -- This configuration is supported, to the extent that the system can
                be booted and a user can be logged in. No claims are made about
                performance. In the case of the 4 MB (megabyte) networked
                system, it is supported only when set up to run all applications
                remotely.
  
MINIMUM RECOMMENDED -- This configuration represents the minimal amount of
                memory recommended for good performance of local applications.
                The number of applications that can be run concurrently without
                degrading performance is also considered to be minimal. See
                the section below entitled "How many Applications?"
  
RECOMMENDED   -- This configuration can be expected to deliver good 
                  performance for a greater number of applications than the
                  minimum (the greater the number of "+" signs, the greater
                  the number of applications). See the section below entitled
                  "How many Applications?"
  
  
Configurations with more memory than that listed here will provide good
performance for an even greater number of applications.
  
  

  
Additional memory generally buys you the capability to run more applications
while retaining good performance for all applications. If an application
already has sufficient memory, additional memory will not necessarily increase
its performance appreciably. If, however, performance of that application has
been lacking due to insufficient memory, its performance will improve when
memory is added.
  
          
HOW MANY APPLICATIONS?
  
The question of how many applications can be run concurrently while maintaining
a good level of performance has no simple answer. It depends on the memory
requirement of each application and on each individual's definition of "good
performance." The following guidelines, while not answering the question
completely, will help you to develop your own impressions of performance
on a given configuration with a given number of applications.
  
Consider the following rules of thumb taken from the VMS Version 5.1
Software Product Description (SPD) for determining supported memory
configurations. (Note that we will use these rules as guidelines in
estimating how many applications to run on a given memory configuration.
If you have questions about whether a particular configuration is supported,
please see the SPD.)
  
  
        Rule of thumb for calculating memory used by various components
                                (in megabytes)
  
  
  
                VMS                     2.0
  
                DECnet                   .5 (required for remote applications
                                               or VAXclusters)
                VAXclusters             1.5
  
                DECwindows              2.0 (1.5 if set up to run all
                                             applications remotely)
  
  
Further, consider the following characterization of application memory
requirements for DECwindows applications.
  
        Rule of thumb for estimating application memory requirements
                           (in megabytes)
  
  
                Small applications       .25
  
                Medium applications      .5
  
                Large applications      1.0 (and above)
  
  
The two sets of rules above can be used to estimate the number of applications
that can be run with good performance on any given configuration. The rules
indicate, for example, that an 8-megabyte standalone configuration requires
4 megabytes for the system (2 for VMS and 2 for DECwindows) and has 4 megabytes 
available for applications. These could be used to provide good performance
for 2 large (1-megabyte) applications, 3 medium applications and 2 small
applications, running concurrently. Note also, that adding 2 megabytes to
an existing configuration allows the addition of, for example, one large
(1-megabyte) application and two medium applications, with no appreciable
loss of performance. 
  
The actual memory requirement of any given application depends on many
factors. It is very heavily dependent upon the application features invoked
by a given user, and varies with time. Techniques involving the use of
working set adjustment and various VMS DCL commands such as MONITOR and
SHOW can be used to classify an application as small, medium or large.
The SPD's of certain layered applications may also include guidelines about
memory requirements.
  
Certainly, more applications than those indicated by these guidelines could
be run, with varying degrees of performance loss. If such additional
applications are run remotely, the effect on performance is minimal.
Alternatively, if they are run locally, but not concurrently with other
applications, the effect on performance may be confined to a transitory
period, after which the expected good level of performance will return.
But, if additional local applications are run concurrently, in excess of the
recommendations above, a noticeable reduction in performance will result.
  
  
WHAT PROBLEMS WILL I HAVE IF MY WORKSTATION DOES NOT HAVE THE RECOMMENDED
AMOUNT OF MEMORY?
  
Problems typical of memory-constrained workstations include an increased overall
page fault or swapping rate, or an increased rate of hard page faults (those
requiring disk I/O). When switching around from application to application,
performance can degrade if paging and/or swapping occurs. This can be seen
in longer window draw and re-paint times and delays in building and activating
menus and dialog (customization) boxes. However, the longer you stay in one
application, the better performance will become, as that application's working
set grows to its WSQUOTA (see guidelines below for setting WSQUOTA).
  
  
ARE THERE ANY MEMORY UPGRADE PROGRAMS AVAILABLE?

Digital is please to offer, for a limited time, a reduced MLP for the 12MB
memory upgrade for the large installed base of VS2000 customers.  The
special price is $6,000, a savings of $3,000 over the regular price. (The
$6000 price is effective now and will expire at the end of Q4FY89 with MLP
reverting back to $9000.)   This upgrade will increase the VS2000 memory
to a total of 14MB. (2MB on the CPU + 12MB memory board.)

There sufficient memory chips to cover this program.  Options projected to
be sold through this offer, are built and in inventory.

See the the following article for more details.

HOW IMPORTANT IS THE CPU IN DETERMINING DECWINDOWS PERFORMANCE?
  
After memory, the workstation CPU is the next most critical resource. Most
things that the typical workstation user does are CPU-intensive operations.
  
Given sufficient memory, you will notice some differences between DECwindows
on a VAXstation-3000 series machine and DECwindows on a VAXstation-2000 series
machine. Although the ratio of raw CPU speed between the machines is closer
to 3:1, in practice we have seen that most CPU-intensive operations are about
twice as fast on a VAXstation-3000 series machine as on a VAXstation-2000, when
applications are run locally. You will notice this in things such as
application startup, the pulling down of menus and the bringing up of dialog
boxes. Cursor tracking also benefits from the speed advantage of the 3000
series machines. This can be seen in things such as the highlighting of menu
items, the dragging of objects such as the window outline,  and all the things
you do in a typical paint application. Finally, applications which do a lot of
writing to the screen will see improvement on the 3000 series. Anything which
does not depend significantly on disk or network I/O should be faster. One
would not expect to see big differences between the 3000 series and the 2000
series in an application with a lot of font-switching or hard page faulting,
both of which would require a significant amount of disk I/O. Similarly,
applications run remotely are usually more dependent on the characteristics
of the remote node and the network than they are on the speed of the
workstation.
  
In general, user actions on a 3000 series workstation with sufficient memory
will feel "crisper" than on a 2000 series workstation with the same amount of
memory.
  
  
WHAT IS THE "TRANSPORT" AND HOW DOES IT AFFECT PERFORMANCE?
  
The transport is the layer of software which controls the transmission
of X protocol messages between the server and its clients. A significant
performance feature of VMS DECwindows is the use of the local transport.
When the server and its client are on different nodes, the transport software
uses DECnet to pass messages back and forth. But, when the server and client
are on the same node, the local transport is used by default. The local
transport uses a very efficient shared memory scheme to effect the exchange
of messages. In applications which are "message-intensive", such as in cursor
tracking applications, the local transport provides a significant speedup over
the DECnet transport.
  
  
WHAT CAN I DO IF MY WORKSTATION LACKS THE AMOUNT OF MEMORY AND/OR CPU
RESOURCES NECESSARY FOR THE PERFORMANCE LEVEL I DESIRE?
  
One of the most powerful features of the X windowing system is its network
transparency. This means it is possible to run your DECwindows applications
on any node on the network and to display the results on your workstation.
It enables you to run your application wherever there are resources that it
needs. Since all user inputs and outputs are still handled by the workstation,
such clients appear as if they are running locally on your workstation.
This is significant from a performance perspective in that it admits a
much broader set of hardware resources for the workstation to draw upon.
  
Presuming that you have access to the resources of other nodes in a DECnet
network, you can run one or more of your application clients on one or more
of those remote nodes. Since most of the memory required by the application
is located on the remote node, this mode of operation can be particularly
beneficial to a workstation with a limited memory configuration. In addition,
further memory savings can be achieved on the remote node by installing
applications with the shared attribute. Finally, the faster CPU of a larger
remote processor may have the effect of speeding up application startup time
and certain aspects of CPU-intensive applications.
  
Applications which have minimal communication with the workstation server
generally run very well remotely. Applications that communicate frequently
with the server to track cursor movement (such as DECwindows Paint), or that
transmit very large blocks of information to the server, generally do not
perform as well. Local execution with sufficient local memory provides the
best and most predictable performance for these types of application.
  
Refer to Appendix A of the "VMS Version 5.1 Release Notes" and Chapter 8 of
of the "VMS DECwindows User's Guide" for more information on the performance
advantages of remote application execution.
  
  
WHAT ELSE CAN I DO TO IMPROVE DECWINDOWS PERFORMANCE?
  
Other suggestions for improving the performance of DECwindows
include:
  
        o Experiment with larger WSQUOTA and WSEXTENT values in the user
                authorization file. Values that you now use may be
                insufficient for DECwindows. It is recommended that WSQUOTA
                be set to the most common application size used. For most
                users, this will be the small (512 pages) or medium
                (1024 pages) application. It is recommended that WSEXTENT
                then be set much larger than WSQUOTA.
  
        o In a VAXcluster, consider the use of a local disk for paging
                and swapping, particularly if your memory configuration
                is below the minimum recommended.
  
        o If you write your own applications, refer to the "VMS DECwindows
                Guide to Xlib Programming" for tips on writing efficient
                DECwindows programs.
  
        o Consider hardware upgrades.
                  
As with any VMS system, the "Guide to VMS Performance Management" should be
consulted for both an overall performance management strategy and specific
suggestions.
  
  
WHAT ABOUT SYSGEN PARAMETER CHANGES?
  
Again, as with any VMS system, SYSGEN parameter changes are not likely
to yield large improvements in performance. AUTOGEN does a reasonable
job of selecting initial SYSGEN values for a VMS DECwindows workstation.
With the FEEDBACK option, AUTOGEN can also refine those values based on
actual workstation usage. Any experimentation with parameters should
be done using AUTOGEN and MODPARAMS.DAT, and then backed out if the desired
improvement is not realized. Several experiments with memory management
parameters were conducted by the VMS performance group during DECwindows
field test. While we saw some success in certain instances, there was
no single clear strategy to recommend for all installations. There are,
however, two memory management changes built into an AUTOGENed DECwindows
system which are new for VMS Version 5.1. By default, you will come up with a
value of 500 for SWPOUTPGCNT. The effect of having SWPOUTPGCNT set to this
relatively high value is that, during a period of peak demand for memory,
swapping will be favored over paging. This behavior is appropriate in a
single-user workstation in order to purge memory of applications which
are idle. The other change involves the FREEGOAL parameter. This parameter
also has a higher value than it did in previous workstation versions. The
effect of this higher value is that, when memory demand is high, VMS will
reclaim many more pages at one time, thereby minimizing the number of times
that reclamation must occur.
  
  
--------------------------- END OF ARTICLE ------------------------------------

I'd like to applaud the DECwindows Performance Team (led by Tom Cafarella)
for their exhaustive (and exhausting) efforts over the last 2 years.

Here is some additional information for DEC-internal users.

IEG transfer cost of the 12mb upgrade board = $1800.00
IEG transfer cost of an 8mb PVAX with disk  = $2100.00

What appears to be an easy choice is actually a bit of a problem...

PVAXes are clearly better in the long run, but IEG probably won't be able
to supply more than a "handful" internally for some time.

12mb upgrades for VS2000s are quite expensive, but they are the best way to
maximize the usefulness of those boxes while they are being depreciated.

My plan is to hedge my bets and order some of each.

		Ken Henderson
		VMS Performance