A special report for all OpenVMS Managers from Touch Technologies Inc. This report was prepared by Touch Technologies, Inc., as a service to the OpenVMS community.
This copyrighted document may be reproduced without formal consent from Touch Technologies, Inc., provided that each copy includes the copyright page in its entirety.
Touch Technologies, Inc. (TTI) has prepared this publication for use by TTI personnel, licensees, and customers. This information is protected by copyright. This document may be copied freely as long as this copyright notice is included in all copies.
TTI believes the information described in this publication is accurate and reliable; much care has been taken in its preparation. However, no responsibility, financial or otherwise, is accepted for any consequences arising out of the use of this material.
The information contained herein is subject to change without notice and should not be construed as a commitment by Touch Technologies, Inc.
When moving from an OpenVMS VAX to an OpenVMS Alpha environment, it is important to understand how OpenVMS Alpha uses memory.
The purpose of this guide is to provide:
This guide is intended for use by the system manager or other technical personnel. The reader is expected to be familiar with OpenVMS utilities such as SHOW MEMORY, SHOW SYSTEM, AUTHORIZE, SYSGEN, and MONITOR PROCESS.
On OpenVMS VAX, a page of memory is 512 bytes. A page on disk is 512 bytes. On OpenVMS Alpha, the size of a memory page can vary from system to system. However, currently the size of a memory page on Alpha is 8192 bytes. This can be verified by these DCL commands:
$ pagesize = f$getsyi("page_size")
$ write sys$output "Page size in bytes: ",pagesize
Use the OpenVMS command SHOW MEMORY on a VAX, and then use the same command on an Alpha system. Notice the large difference in Total, Free, In Use, and Modified pages!
VAX$ show memory/physical
System Memory Resources on 22-APR-1995 18:02:42.92
Physical Memory Usage (pages): Total Free In Use Modified
Main Memory (64.00Mb) 131072 102192 28000 880
.
.
Alpha$ show memory/physical
System Memory Resources on 22-APR-1995 17:59:10.86
Physical Memory Usage (pages): Total Free In Use Modified
Main Memory (64.00Mb) 8192 3504 4251 437
Because the memory page size isn't 512 bytes anymore, it it possible for an application on Alpha to use fewer pages than the same process on VAX, but consume much more memory!
If you are on a VAX system and press CTRL/T, the memory shown is in pages if 512 bytes. On an Alpha system, the memory shown is in pages of 8192 bytes (or whatever the page size is for that system). Here is an example:
VAX$ GUEST 18:30:05 (DCL) CPU=00:00:00.16 PF=273 IO=394 MEM=359 . . Alpha$ GUEST 18:27:10 (DCL) CPU=00:00:03.41 PF=650 IO=489 MEM=55
Digital has a new terminology to describe chunks of 512 bytes of memory. A chunk of 512 bytes of memory is a pagelet. A pagelet on VAX is 512 bytes. A pagelet on Alpha is also 512 bytes. Therefore, in order to make sense of memory usage comparisons between VAX and Alpha, all further discussions will be in terms of pagelets.
VAX architecture is as CISC architecture. This generally that a single machine instruction can stand for a very complex operation---such as string search and compare. The C in CISC stands for Complex.
Alpha architecture is a RISC architecture. This means that the machine instructions are kept very simple. A RISC architecture uses many more machine instructions than a CISC architecture to accomplish the same task. Typically 1.5-3 times as many instructions.
So, why is everyone going to RISC? Because RISC allows less complex chips to be built---by virtue of its reduce instruction set needs. Less complex chips are easier to scale up in speed than CISC chips.
It can take 1.5-3 times as many RISC instructions to accomplish a single CISC instruction. Each instruction takes up address space (virtual or physical memory). So, not surprisingly enough, application running on a RISC system can take 1.5-3 times as much memory as they did on a CISC system.
Alpha systems are RISC, VAX systems are CISC. So, you can expect applications on your Alpha system to require 1.5-3 times as much address space (virtual memory) as they did on your VAX computer! if you needed 64MB of memory to handle 20 users on your VAX, you can expect needing 128MB of memory or more on your Alpha system to run the same number of users and the same application!
Most of the space in an OpenVMS runnable image (.EXE file) is taken up with machine code. Since Alpha systems are RISC architecture and require more instructions and more virtual address space than VAX systems, runnable images on Alpha systems are larger than their VAX counterparts---1.5-3 times larger!
For example, lets look at SYS$SYSTEM:SET.EXE on both the VAX and Alpha systems:
VAX$ dir sys$system:set.exe/size Directory SYS$COMMON:[SYSEXE] SET.EXE;1 289 . . ALPHA$ dir sys$system:set.exe/size Directory SYS$COMMON:[SYSEXE] SET.EXE;1 449
Each process has a working set list. The working set list is a list of pointer to chunks of physical memory that this process can use. If the process needs to access address space that is not pointed to by its working set list, the process will page fault. The page fault will cause OpenVMS to try to find the needed address space for the process.
If the requested address space can be found on the Free List or Modified List, OpenVMS will soft fault the page into the working set. In order to soft fault a page into the process's working set, OpenVMS just changes a number of memory-pointers. This pointer change is performed at CPU speeds. On an Alpha system, this can be as fast a 1,000,000,000 instructions per second!!
If the requested address space can not be found on the free list or Modified List, OpenVMS must Hard Fault the page into the working set. In order to Hard Fault a page into the process's working set, OpenVMS must access the disk first. After the page is brought into memory from disk, memory-pointers are changes to attach the page to the process's working set. A very fast disk drive will take 10ms or longer to bring the page in from disk. The process of Hard Faulting takes over 1000 times longer than Soft Faulting!
It is important to note the difference between the WORKING SET and the WORKING SET LIST.
The WORKING SET LIST (WSL) is made up of pointers to each page in the working set (WS). The size of each working set is therefore limited by the number of pointers in the list.
OpenVMS grants physical memory to a process by increasing the size of the WSL, but it is then up to the process to make use of the extra memory. The memory is used when the process faults pages into the process working set.
Working set list adjustment is controlled by the following system parameters:
| Parameter | Description |
|---|---|
| AWSTIME | CPU time to be reached before AWS can occur |
| WSINC | number of WSL entries added by AWS |
| WSDEC | number of WSL entries removed by AWS |
| PFRATH | page fault tolerance rate |
| PFRATL | page fault encouragement rate |
The following parameter values are recommended to keep AWS overhead at a reasonable minimum:
| Parameter | Recommend Value |
|---|---|
| AWSTIME | 60 or more |
| WSINC | 503 |
| WSDEC | 19 |
| PFRATH | 10 |
| PFRATL | 1 |
In 1987, Touch Technologies, Inc. (TTI) developed Dynamic Tuning for OpenVMS (OpenVMS was just called VMS back then). This product was called The Dynamic Load Balancer. Now, TTI has released Dynamic Load Balancer Plus (DLBP) for OpenVMS VAX and OpenVMS Alpha!
Dynamic Load Balancer Plus works by keeping a history on the memory needs and page fault behavior of every process on the system. This history, along with a proprietary Expert System built-in to DLBP, is used to determine which processes need more memory pages and which processes have unused memory pages.
Unused pages of memory are taken from memory rich processes and given to memory poor processes. Using process memory and page faulting history information kept by DLBP, along with Expert System predictions of future process memory needs, DLBP is able to decrease hard faults and eliminate unnecessary soft page faults. The net effect is much better overall system performance. In addition, the reduction of hard page faults decreases I/O activity...even helping systems that are I/O bound.
RISC systems (Alpha) consume substantially more memory than their CISC counterparts (VAX). When purchasing an Alpha system, remember to purchase 1.5-3 times more memory than you had on your VAX system. And, to keep that memory fully utilized, and to avoid costly Hard Page Faults, purchase a copy of Dynamic Load Balancer Plus---to keep your system perfectly tuned at all times.