RD/EE Controls<P> EPICURE Software Design Note 110.0<P> <b> Results Of VAXELN/DECwindows Testing</b>

RD/EE Controls

EPICURE Software Design Note 110.0

Results Of VAXELN/DECwindows Testing

Debra S. Baddorf and Brian J. Kramper

Over the past several months we have been testing the feasibility of running VAXstation 2000s as X terminals by using VAXELN with its DECwindows windowing system, EWS, and a host system. In this configuration the VAXstation 2000 is booted over the network from one of the nodes in the WARNER cluster which has sufficient CPU and memory resources to accommodate this testing. The VAXstation 2000 then acts as merely a terminal; the user actually logs into the host system and uses its resources. Therefore, the host's resources must be accounted for before blithely deciding to turn all 2000's into EWS nodes.


For our purposes we chose two VAXstation 3100 Model 38s and a VAXstation 3200 as the hosts at different times. The VAXELN workstations were mostly VAXstation 2000s, though a VAXstation II was tested also. Figure shows the nodes and hardware configurations which were used at various times during the test period.

The initial testing of VAXELN with EWS was done on TWEETY and RDTEK1 with the host downloads coming from BASIL. BASIL also serves as a core node for the WARNER cluster. As such it services other interactive user processes, batch jobs, Appletalk server and symbionts, and standard Epicure services (DAR, ARD, DBserver). Later testing used node BADORF as the host, since it runs fewer tasks besides VMS and the windows. Node BADORF is itself a DECWindows VAXstation, so the host workstation screen was counted as one X-user for memory usage calculations.

The base window configuration for our testing consisted of two types of users: developer and system manager. The developer user at login was started up with a window manager, a session manager, four DECterm terminals, Mail and Calendar. This user frequently ran an X application doing rapid screen output. The system manager was started up at login with the same configuration, adding two or three more DECterm windows as necessary. Usage patterns involve rapid switching between windows and various DCL tasks.


The typical boot time for a node running VAXELN is 1 minute. A typical login time under DECwindows for a session manager with a single terminal window is 55 seconds. This was measured using host BASIL and EWS node RDTEK1. The typical boot time for workstation WRNADT running VMS and UIS on the same cluster was 24 minutes. The typical login time for a single terminal window under UIS was 30 seconds. Note that these are merely reference points for comparison and do not represent normal running conditions for developers on the WARNER cluster. Normally a developer has several windows open and active at any one time.

VS2000 Memory

The VS2000s had from 6 MB to 10 MB of memory. Using the built-in memory display of EWS, we were able to monitor local memory usage under different conditions. Initially about 4 MB was used for VAXeln and normal screen management. This varied very little with the number of applications and/or windows either on the screen or iconized. The one anomaly we did note occurred when we used a public domain program to display GIF files under DECwindows. For a GIF file which used virtually the entire screen, about 1.25 MB was allocated from local memory. This memory appears to be re-used for subsequent GIF files, but does not seem to be returned to the system until the user logs off.

Host Memory

It was very difficult to ascertain exactly how much memory was needed for any given application, even the standard ones supplied by DEC such as Mail, Calendar and DECterm. VMS is designed to assign memory to a process as it is needed, and to shuffle memory allocations as another process requests more memory. Therefore, stating categorically that a process needs a certain amount of memory is not possible. Figure shows the observed memory usage in 512-byte pages for some common applications on the WARNER VAXcluster.

It was observed that Mail seemed to determine the necessary number of pages needed at its initialization by the number and size of the outstanding unread messages. This number was not observed to be reduced except by exiting and re-entering the application after reading all the unread messages. The DECterm application, on the other hand, seemed to freely give up memory as it was used until it got down to about 300 pages.

The Calendar application seems to use the lower memory figure when it is never used at all. Once the application is un-iconized and actually used, memory usage followed a pattern we were not able to completely understand. However, the more the calendar is used (merely looked at, daily entries looked at, entried added or modified) the more memory it requires. This memory requirement seems not to go away until perhaps the following day; merely exiting and re-starting the application did not release the larger memory requirement.

DEC has suggested that the average application would need about 1 MB or 2000 pages of memory on the client machine. If we were to use this as a starting point, then the average developer on the WARNER cluster should be allocated between 8 and 12 MB on the client.


In addition to looking at the memory and CPU power requirements for this type of running condition, we also looked at the effect this had on the local network, since this could generate a significant amount of network traffic. A LAN monitor was used to monitor a bridge on the WARNER side of the brouter which separates its private ethernet segment from the main backbone. The WARNER cluster normal sees from 8 to 12 per cent of the bandwidth in use. Spikes in network traffic were noted into the 25-30% range during login and at the startup of other applications, but the EWS X window usage as a whole amounted to only a 1 to 2% increase in the overall bandwidth. This test was with 4 such EWS nodes running.


For purposes of system management and development we would propose that a figure of 8 to 12 MB be used for each EWS node on a given host. This would be in addition to whatever memory is consumed by VMS itself. This number may seem conservatively large, but we feel it would be better to err on the side of excess rather than to be consistently running out of memory and crashing developers' workstations.

These nodes should probably not serve much in addition to these EWS users. Terminal usage is probably allowable, especially in the case of 8-user licenses, but batch queues and perhaps even print queues should be relegated to other available nodes in the core.

Minimum memory required on the VAXstation 2000 is 6 MB, although this seems to be borderline. A system with 8 MB would be better, and 10 MB should be sufficient for any user.

The network usage will increase 1% or less for each EWS user added to a cluster/segment, but this will eventually add up to a significant amount. This is further reason for minimizing the amount of traffic from other users on a developers' segment.

Security, Privacy, Legal