CHAPTER VAX PAGESWAPPER - November 1985 - Volume 7 Number 4 VAXstation User Interface Service . . . . . . . VAX-3 DSA Disks for the MicroVAX II . . . . . . . . VAX-10 Heterogeneous VAX Clusters . . . . . . . . . . VAX-11 Adjusting Working Set Parameters for Users . . VAX-21 Editor's Workfile . . . . . . . . . . . . . . VAX-36 Notes from the European Symposium . . . . . . VAX-37 VAX System SIG Committee List . . . . . . . . VAX-41 INPUT/OUTPUT . . . . . . . . . . . . . . . . . VAX-44 Forms at the End INPUT/OUTPUT Submission Form . . . . . . . . . VAX-46 System Improvement Request Submission Form . . VAX-48 PAGESWAPPER - November 1985 - Volume 7 Number 4 General material for publication in the Pageswapper should be sent (US mail only -- no "express" services please) to: Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station Cambridge, MA 02139-0901 USA Preference is given to material submitted as machine-readable text (best is Runoff source). Line length should not exceed 64 characters. Please do not submit program source, as that is better distributed on the VAX SIG tape. Change of address, reports of non-receipt, and other circulation correspondence should be sent to: DECUS U.S. Chapter Attention: Publications Department 249 Northboro Road (BPO2) Marlborough, MA 01752 USA Only if discrepancies of the mailing system are reported can they be analyzed and corrected. VAX-2 PAGESWAPPER - November 1985 - Volume 7 Number 4 VAXstation User Interface Service VAXstation User Interface Service by Larry Kilgallen At the European DECUS Symposium in September, Jake Vannoy of DEC described the User Interface Service (UIS) Programming Interface to the VAXstation which is being documented for the first time with Version 2 of the VAXstation software. +---------------------------------------------------------------+ | User application | | program | +---------------------------------------------------------------+ | | | | | | +---------+---------+ | | | | RMS I/O | SMG/SCR | | | | +---------+---------+ | | | \ / | | | \ / | | | | | | | | | | +-------------------+ +-----------------------+ | | Industry standard | | TT class driver | | | graphics packages | +-----------------------+ | | (GKS, etc) | | Terminal emulators | | +-------------------+ | (VT100, TEK4014) | | | +-----------------------+ | | | | | | | | | | +---------------------------------------------------------------+ | UIS Interface | +---------------------------------------------------------------+ | | | | | | Windowing | Graphical | Input and | Display List | | | Output | Interaction | | | | | | | +---------------------------------------------------------------+ | / \ | / \ | / \ | / \ | / \ /-------------\ +---------+ \ / ___ / \ |..... ...| OO/___\___ / \ +---------+ /-------------------\ Display Keyboard Mouse VAX-3 PAGESWAPPER - November 1985 - Volume 7 Number 4 VAXstation User Interface Service While Version 1 of the VAXstation software had documentation only for the terminal emulators (VT100 and TEK4014) and the industry standard graphics interface (GKS), Version 2 includes documentation for the lower level UIS user interface subroutines which the other interfaces invoke. Through direct UIS calls, a user with no need for program portability to the computers of other manufacturers can obtain some graphics services not available through the GKS and terminal emulator interfaces. Basic Terminology Graphic output via UIS is described in terms of virtual displays, display windows and viewports. A "virtual display" is a device independent (not bitmap) output entity which a user can write to through appropriate calls to UIS entrypoints. The coordinate system is application-defined, and a virtual display need not necessarily be presently visible on (mapped to) the physical display. As would be expected, there can be multiple virtual displays per application. A "display window" is a portion of a virtual display which is currently mapped for output. A "display viewport" is a portion of the physical display. Every display window has an associated display viewport, and graphic data within the display window is automatically scaled to the display viewport. There may be many display windows for the same virtual display, and there may be many viewports on the physical display, so various portions of a single virtual display can be shown in various positions and scales on the physical display at the same time. Sample UIS calls Vannoy made notes available at his talk which gave a flavor for the calling sequences of the UIS interface. For example, to create a display and a window: vd_id = UIS$CREATE_DISPLAY (0.,0.,1.,1.); specifying a coordinate system and returning UIS-generated display id. wd_id = UIS$CREATE_WINDOW (vd_id, "TEST WINDOW"); VAX-4 PAGESWAPPER - November 1985 - Volume 7 Number 4 VAXstation User Interface Service specifying a window name and returning UIS-generated window id. UIS$DELETE_WINDOW (wd_id); UIS$DELETE_DISPLAY (vd_id); o Output primitives modify the virtual display - UIS$TEXT - draw text string - UIS$PLOT - Draw point, line, or polyline - UIS$CIRCLE - Draw circle - UIS$ELLIPSE - Draw ellipse - UIS$IMAGE - Draw natural image (bitmap graphics) o "Attribute blocks" specify appearance - specified by number (0-255) - functions exist to get and set specific attributes - example: UIS$SET_LINE_WIDTH (vd_id, 0, 1, 0.1); where 0 specifies an old attribute block to be copied, 1 specifies a new attribute block to be created, and 0.1 specifies the desired width in the new attribute block. UIS$SET_WRITING_MODE (vd_id, 1, 1, "complement"); where the old and new attribute block are the same, so an existing attribute block is modified. UIS$PLOT (vd_id, 1, 0.,0., 1.,1.); where 1 specifies the attribute block to use and the other numbers are coordinates. o Attribute Block Scope - Graphical BEGIN/END blocks limit the scope of attribute blocks VAX-5 PAGESWAPPER - November 1985 - Volume 7 Number 4 VAXstation User Interface Service - Output primitives are grouped into "segments" UIS$BEGIN_SEGMENT UIS$END_SEGMENT - Segments may be nested - Segments inherit attribute blocks of higher level segments - Attribute changes affect only the local copy o Display lists - UIS records what is drawn in the virtual display (if the display list feature is turned on) - recorded display list is retained by UIS so applications can easily: 1. pan the display: UIS$MOVE_WINDOW 2. zoom the display: UIS$MOVE_WINDOW 3. copy the display: UIS$CREATE_WINDOW - Display list recording can be turned on and off 1. UIS$ENABLE_DISPLAY_LIST 2. UIS$DISABLE_DISPLAY_LIST - Display lists can be edited 1. UIS$ERASE 2. UIS$MOVE_AREA Virtual keyboards are analogous to a virtual display. There can be multiple virtual keyboards per application, and keyboard attributes and reads are all associated with virtual keyboards. The question of which virtual keyboard the physical keyboard applies to at a particular time is managed by the user. o Creation and deletion of virtual keyboards UIS$CREATE_KB VAX-6 PAGESWAPPER - November 1985 - Volume 7 Number 4 VAXstation User Interface Service UIS$DELETE_KB o Seizure and release focus of physical keyboard UIS$ENABLE_KB UIS$DISABLE_KB o Enable user interface for focus of physical keyboard UIS$ENABLE_VIEWPORT_KB UIS$DISABLE_VIEWPORT_KB o Test connection to physical keyboard UIS$TEST_KB o Notification that window operations have occured UIS$SET_GAIN_KB_AST UIS$SET_LOSE_KB_AST o Set keyboard attributes UIS$SET_KB_ATTRIBUTES UIS$GET_KB_ATTRIBUTES UIS$SET_KB_KEYTABLE UIS$SET_KB_COMPOSE2 UIS$SET_KB_COMPOSE3 o Enable asynchronous input UIS$SET_KB_AST o Perform synchronous input UIS$READ_CHAR o Keyboard output functions UIS$SOUND_BELL UIS$SOUND_CLICK Pointer (mouse) input functions are sensitive to window rectangles; they can be armed for a particular region of the screen. Call include: o Change cursor pattern (a 16 x 16 pixel pattern) UIS$SET_POINTER_PATTERN VAX-7 PAGESWAPPER - November 1985 - Volume 7 Number 4 VAXstation User Interface Service o Button input (both down transitions and up transitions) UIS$SET_BUTTON_AST o Pointer movement UIS$SET_POINTER_AST UIS$GET_POINTER_POSITION o Viewport-independent pointer input (relative to physical screen) UIS$GET_BUTTONS UIS$GET_ABS_POINTER_POSITION The UIS entrypoints in general perform their work in the access mode of the caller, and the VAXstation bit-mapped display is mapped into system address space as user-writeable memory. Therefore, even though it is possible to write to the physical display in kernel mode (I would presume this is the case for the terminal emulators executing in driver context), it is not required, and user calls to UIS routines incur only the overhead necessary to perform the graphics functions, avoiding VMS QIO overhead. UISDC Graphics Interface For those who insist on getting even closer to the hardware, the next lower level interface provided with version 2 of the VAXstation software is a Device Coordinate UIS interface, where viewports are specified in relative integer pixel coordinates, instead of floating point world coordinates. No coordinate transformations are performed and the display list described above is not maintained. The UISDC calls can be used concurrently with the world coordinate UIS calls. QVSS Graphics Interface If the above interfaces are not of a sufficiently low level, Version 2 of the VAXstation software also documents an even lower level, where the user can communicate directly with the device driver, writing raster operations and a windowing system VAX-8 PAGESWAPPER - November 1985 - Volume 7 Number 4 VAXstation User Interface Service to meet particular needs. This form of access does not coexist with UIS applications and windows as described above. QIO primitives at this level include: o initialize the screen o enable keyboard input o modify keyboard characteristics o modify system characteristics o enable mouse button ASTs o enable mouse movement ASTs o define mouse cursor pattern o access reserved function keys o sound keyboard o maintain user entry list o get QVSS characteristics Off the subject of the new programming interface, Vannoy indicated that there is incompatibility between some VMS software and the way that virtual terminals are created for the VAXstation. The virtual terminals are template devices, so when one does an $ASSIGN to unit 0 one actually ends up creating (and getting a channel assigned to) some other unit. Assigning a second channel to the same device you assigned the first channel to does not work; you have to do a $GETDVI to find out what unit you actually got before doing the second $ASSIGN. Not all of DEC's software does this. I think it is fair to presume that not all the affected user software does so either. VAX-9 PAGESWAPPER - November 1985 - Volume 7 Number 4 DSA Disks for the MicroVAX II DSA Disks for the MicroVAX II by Larry Kilgallen With the announcement of DSA disks for the MicroVAX II "imminent" to use the words of one DEC manager, information about that support was much more available at the European Symposium than it has been at the Spring US Symposium. KDA50 Q-bus DSA controller Clark Lubbers from DEC in Colorado gave a talk on the KDA50 interface and said that he believes it will outperform the UDA50 (primarily because of the availability of block mode transfers on the Q-bus). He said the interface consists 2 quad modules, making it smaller than the UDA50. He said its speed matching buffer is slightly smaller (41 sectors vs 56 for the UDA50). Lubbers described seek ordering (elevator algorithm with fairness counter) as being equivalent to the UDA50 and said that compared to not doing seek ordering there was a performance gain of up to 35 percent. Likewise he said other optimizations performed by the KDA50 were equivalent to the UDA50. Turning to differences between the unit and its Q-bus relative, Lubbers said the burst rate for block mode transfers could be varied from 1 to 16 words BY THE HOST, and he said the asymptotic throughput approached with a setting of 16 was 880 kilobytes per second, as compared with 750 for the UDA50. Cabinetry At other sessions during the week, DEC speakers indicated the new cabinet (H9642?) to hold DSA disks along with a MicroVAX will be similar to a three DSA disk cabinet but with the center disk position taken up by the MicroVAX in TWO rack-mounted BA23 backplanes. They said there would be 10 large I/O connector slots (multiplexers or network) and 6 small I/O connector slots (parallel devices). They described the top third of the cabinet as being available for an RA60 or RA81 disk drive or a TSV05 CSS tape drive, while the bottom third could ONLY be used for an RA81. VAX-10 PAGESWAPPER - November 1985 - Volume 7 Number 4 Heterogeneous VAX Clusters Heterogeneous VAX Clusters Don Golden Shell Oil Company With its introduction of the VAXcluster, Digital Equipment Corporation has taken the lead in the loosely coupled multiprocessor arena. No other manufacturer makes it so easy to upgrade a configuration by adding processing power. By properly configuring a VAXcluster, it can grow from one processor to two to several, without major down time for reconfiguring equipment and users. The remarkable thing is that the various processors participating in a VAXcluster can support applications that all access the same database simultaneously. VAXclusters configured in this way are known as homogeneous VAXclusters. The key characteristic, and I might add, strength, of a homogeneous VAXcluster is that to the user, there is no distinction among the machines in the cluster. The machines typically share a common user authorization file, a common collection of logical names to define the mass storage, a common disk mounting procedure and a common set of batch and print queues. With the local area terminal server working as a load balancer, the user shouldn't really care which machine he or she is logged onto. Furthermore common generic batch queues make another contribution to sharing and balancing the load among the machines. For many classes of applications, the individual machines in a homogeneous VAXcluster perform as a single more powerful machine. There are other ways to configure a VAXcluster than as a homogeneous one. When it is desirable for some of the machines to participate in a common environment while other machines in the cluster 'march to a different drummer', then a heterogeneous VAXcluster is the answer. This is the way to share some portion of the common resources while allowing machines to retain their own distinct 'personalities'. The VMS Version 4 documentation does a reasonably good job of describing how to make a homogeneous VAXcluster work. For the system manager who has the task of making the heterogeneous VAXcluster play, the trail to success is less well marked. Hopefully, this article contains some valuable hints that will make implementation of a heterogeneous VAXcluster less of a mystery. At Shell Oil Company's Westhollow Research Center, the Control Engineering and Manufacturing Computer Systems Group is tasked to apply advanced computer technology to the problems of controlling petrochemical manufacturing processes. Several years ago, the VAX/VMS architecture was selected as our vehicle VAX-11 PAGESWAPPER - November 1985 - Volume 7 Number 4 Heterogeneous VAX Clusters for implementing our process control system. Since that time, our development and test system has grown from a single VAX 11/750 to a six node VAXcluster with two 11/785's along with four 11/750's. The following figure illustrates our VAXcluster, at least from a hardware standpoint. +--------+ +--------+ +--------+ +--------+ | 11/785 | | 11/785 | | 11/750 +-+ | 11/750 | ++---+---+ ++---+---+ +-+--+---+ | ++---+---+ +--+-+ | +--+-+ +---+ +-+ | +--+-+ +--+-+ | |TU80| | |TU80| | | | |RA80| |RM80| | +----+ | +----+ | |+---++ +----+ +----+ | | | ||TU77| |RA80| | | | |+----+ +----+ | +------------------+| |+--------------------+ +--------+ +++--++-+ +--------+ | 11/750 +-------------+ STAR +-------------+ 11/750 | ++------++ ++-----++ +-+-----++ +--+-+ +--+-+ | | +--+-+ +-+--+ |TU80| |RA81| | | |TU80| |RA81| +----+ +----+ +-------+ +---------+ +----+ +----+ | | | | | +----------+ | | +--+ RA81-0 +--+ | +---+-+ | +----------+ | ++----+ |HSC50+-+ +----------+ +-+HSC50| +-----+ +--+ RA81-1 +--+ +-----+ | +----------+ | | +----------+ | +----------+ +--+ RA81-2 +--+ +-+ RA81-5 +-+ | +----------+ | | +----------+ | | +----------+ | | +----------+ | +--+ RA81-3 +--+ +-+ RA81-6 +-+ | +----------+ | | +----------+ | | +----------+ | | +----------+ | +--+ RA60-4 +--+ +-+ RA60-7 +-+ | +----------+ +------+ +----------+ | +--------------------------------------+ It is impressive to see six machines all playing by the same rules and working together in a cluster. It is even more impressive to understand that each of these machines is doing its own job, relatively independently of the others. It is this disparity of goals assigned to the various machines that prompted us to implement a nonhomogeneous VAXcluster. With several versions of our process control software delivered and working in manufacturing locations, we need to be able to quickly bring up a given version to verify errors or discrepancies. We also have several ongoing, but separate, development efforts which tend to collide in unpleasant ways unless segregated by machine. We are generating interim releases of our software and performing ongoing regression tests. And finally, we are always able to run the 'latest and VAX-12 PAGESWAPPER - November 1985 - Volume 7 Number 4 Heterogeneous VAX Clusters greatest' new release in a demonstration mode to impress our users and to hopefully win new friends. To perform all these things without the heterogeneous VAXcluster would require more machines than the six that cohabitate in our cluster. The storage in our VAXcluster is in a variety of forms. A pair of HSC50 mass storage controllers tie a 'disk farm' of RA81's and RA60's into the star coupler. The 11/750's each have their own RAxx storage attached to the machines by UDA50 controllers. Also available on the cluster are a dual floppy drive and an RL02 although these devices get very little play. In our VAXcluster, the two 11/785's serve as our development machines where developers edit, compile and link programs. These two machines also 'own' the multiple CMS libraries that hold the source code for the process control system. Finally, these machines produce the 'generations' of our software package for testing and release to the field. This last operation requires on the order of 16 hours of 11/785 time so we tend to do this operation on the faster machines on behalf of the 11/750's in the cluster. The four 750's tend to be reconfigured from time to time, but generally serve as the test beds for running test generations and production releases of our software. The process control package comprehends a multinode computer system linked by Ethernet so we can readily product several combinations such as: 1. A four node system 2. Two two node systems 3. Two one node systems and a two node system 4. Many other alternatives. This is accomplished by booting from different roots on different disks on the mass storage farm. Typically, one 785 and one 750 tend to operate as a homogeneous cluster both sharing the same system disk, but different roots. The second 785 boots from another root on this system disk, but contains more customization in its root in order not to share too much with the other two. The remaining systems typically boot from their own system disks, which are not configured as clustered VMS system disks, but rather as single system disks. These systems can also boot from disks mounted on RA60's in the 'disk farm' to do a short term stint in some other configuration. VAX-13 PAGESWAPPER - November 1985 - Volume 7 Number 4 Heterogeneous VAX Clusters How did we get there? To be truthful, I'm not sure. However, I will try to reconstruct the roadmap and leave you some pointers to keep you from heading off toward a dead end. Rule 1: If you ever intend to have a common rooted VMS system, do it up front. When installing the VMS 4.0 upgrade, VMS looks for the CI hardware and if it is found it builds the common system disk version of VMS. This on disk structure puts the sharable parts of VMS into a common root structure. This root structure is then made available to each of the distinct operating roots through the magic and mirrors of logical names and search lists. If you plan for more than one machine to boot from a common disk in your VAXcluster then it will be far easier to start with this configuration than with a disk configured for a single, non-clustered system. Rule 2: Get the SCS parameters right. Sometimes when modifying the SYSGEN parameters, the SCS parameters can become mangled. One neat way to do this is to do an AUTOGEN without doing a SAVEPARAMS phase first. The symptom of such ham handed behavior will be a VAXcluster that doesn't come up, comes up but complains vehemently and persistently, or comes up in a 'weird' mode. The best example of a weird mode is when one supposed participant in the VAXcluster has the SYSGEN parameter VAXCLUSTER set to zero, inadvertently. This joker comes up and runs in in what appears to be a reasonable manner, but the other participants in the VAXcluster don't like the interloper using their hardware without joining their club and they really complain. {One side point: SCS loves to type stuff on every console it can get access to. I am not sure that DEC hasn't acquired an interest in some paper production concern. Some of these messages are OK, but many of them are just an annoyance and mask real problems by their everpresence.} The System Communications Service lives between the bulk of VMS and the cluster hardware. It keeps the various machines happy and apprised of one another. It is vitally important that all the SYSGEN parameters controlling this piece of the operating system be correct. On the initial, conversational, boot of the system you must enter SCSSYSTEMID to get the ball rolling. If you blow this one, SCS will cast a plague on your cluster that will make you wish you knew how to repent of your evil ways. The SYSSYSTEMID is no longer the same as the address cranked into the CI hardware by the field service folks and displayed in the hexagonal badge plastered on the front of the machine. It is now the decimal equivalent of the DECnet address of the machine passed through a small conversion formula. SCSSYSTEMID = 1024*(DECnet area) + (DECnet node number) VAX-14 PAGESWAPPER - November 1985 - Volume 7 Number 4 Heterogeneous VAX Clusters Thus if your DECnet address is (or is to be) 2.4 then your system id will be 2052. It is also quite courteous of you to enter the SCSNODE parameter. This is the DECnet nodename and is also entered via SYSGEN or during a conversational boot via SYSBOOT. Don't forget to set VAXCLUSTER to 1 or you won't have one. Rule 3: Heterogeneous VAXclusters, even if they use a disjoint set of disks, can use a quorum disk! This is perhaps the neatest single fact discovered in the series of trials and errors that lead to the working VAXcluster. When we initially began to cluster our machines, we had a two node homogeneous cluster and we used a quorum disk. This allowed either machine to depart or rejoin the VAXcluster, rather indiscriminately, without causing the other machine to go into an identity crisis over the loss of a cherished 'club' member. In adding a third node, the one which changed the VAXcluster from a homogeneous one to a heterogeneous one, we removed the quorum disk from the SCS parameters. The effects of this were not devastating except when we wanted to go from three live and kicking nodes to one. The one remaining node was so distraught at losing its 'lodge' members, that it stalled in an SCS snit. The Guide to VAXcluster is really unclear on this point, but if there is a common disk, served by an HSC50, it can be declared as a quorum disk in order to improve the availability of the VAXcluster. This is true whether or not the members of the VAXcluster intend to mount this disk later or not. I believe that it helps if each participant eventually mounts the quorum disk, but it is not required. The SCS software can try to get to the quorum file entry regardless. Rule 4: Use MOUNT/CLUSTER with a logical name with care. Once we got the heterogeneous cluster to come up without getting confused about membership, we wanted to get some disks mounted in order to begin doing useful work. I liked the sound of the MOUNT/CLUSTER command so I replaced all the MOUNT/SYSTEM commands in the various startup files with MOUNT/CLUSTER. This would have been OK except that most of our MOUNT/SYSTEM commands ended with a logical name to be attached to the device. What I learned was that one machine's USERDISK may be another machine's TESTDISK. Logical names apply machine wide, not cluster wide. It was OK to do the mount with the /CLUSTER qualifier, but logical names should be assigned separately so that disks can take on different identities on different machines. Corollary to rule 4: Be careful in your disk labeling conventions. In our shop we had typically labeled the disk where all the user directories lived as USERDISK and mounted it with the logical name USERDISK. I don't think this is remarkably different from many VAX installations in the world. VAX-15 PAGESWAPPER - November 1985 - Volume 7 Number 4 Heterogeneous VAX Clusters When several machines each want their own USERDISK in a VAXcluster the physical volume labels cannot all be USERDISK any machine wants to mount more than one of them with the /SYSTEM qualifier, much less the /CLUSTER qualifier. Rule 5: Sharing a queued device means sharing all queues. One of the real economies we achieve with the VAXcluster is that two really fine, high speed printers can be made available to all of the machines in the cluster. The price we paid is that every node in the cluster has a view of all of the print and batch queues on the cluster. This is because JBCSYSQUE.DAT is maintained by the cluster manager in a shared manner. If it is private to a node, all well and good, but if any part is to be shared, it must be in a common directory, available to all members of the VAXcluster. Both our print and batch queues are set up by command files similar to the ones in chapter 3 of Guide to VAXclusters. We made some changes, to make them work for us. PRINTQUE.COM $ SET NOON $ ! Get our node name $ Node = F$GETSYI("NODENAME") $ $ ! Set up some start symbols $ $ WP2DV0_Start = "/NOSTART" $ WP2DV1_Start = "/NOSTART" $ WP2INF_Start = "/NOSTART" $ WP2CN0_Start = "/NOSTART" $ WFTINF_Start = "/NOSTART" $ WFTCN0_Start = "/NOSTART" $ $ ! Now redefine me $ $ 'Node'_Start = "/START" $ $ DEFINE/FORM/WID=80/NOTRUN/NOWRAP DEFAULT 0 $! $! The above command makes our standard form be 80 $! columns wide so we can cut the print down and $! put it into a notebook with header pages. $! $IF Node .eqs. "WP2DV0" - THEN SET DEVICE/SPOOLED=(WP2DV0_LCA0) LCA0 $IF Node .eqs. "WP2DV0" - THEN SET PRINTER LCA0 /LP11 /PAGE=64 /LOWERCASE /FF /CR $IF Node .eqs. "WP2DV1" - THEN SET DEVICE/SPOOLED=(WP2DV1_LCA0) LCA0 $IF Node .eqs. "WP2DV1" - THEN SET PRINTER LCA0 /LP11 /PAGE=64 /LOWERCASE /FF /CR $INITIALIZE/QUEUE/DEFAULT=FLAG/ON=WP2DV0::LCA0 - VAX-16 PAGESWAPPER - November 1985 - Volume 7 Number 4 Heterogeneous VAX Clusters 'WP2DV0_START' WP2DV0_LCA0 $INITIALIZE/QUEUE/DEFAULT=FLAG/ON=WP2DV1::LCA0 - 'WP2DV1_START' WP2DV1_LCA0 $INITIALIZE/QUEUE/START/GENERIC=(WP2DV0_LCA0,WP2DV1_LCA0) - SYS$PRINT The SET DEVICE/SPOOLED lines in the file above are important to how we use the printers in our DECnet configurations. We use the command COPY file NODE::printer to print files on remote nodes. The queue name must be defined in the SET DEVICE command line to allow this important 'printer saving' command to work. BATCHQUE.COM $ SET NOON $ ! Get our node name $ Node = F$GETSYI("NODENAME") $ $ ! Set up some start symbols $ $ WP2DV0_Start = "/NOSTART" $ WP2DV1_Start = "/NOSTART" $ WP2INF_Start = "/NOSTART" $ WSPAR2_Start = "/NOSTART" $ WFTINF_Start = "/NOSTART" $ WFTCN0_Start = "/NOSTART" $ $ ! Now redefine me $ $ 'Node'_Start = "/START" $ $INITIALIZE/QUEUE/BATCH/JOB_LIMIT=5/BASE_PRIORITY=4 - /ON=WP2DV0::'WP2DV0_Start' WP2DV0_BATCH $INITIALIZE/QUEUE/BATCH/JOB_LIMIT=1/BASE_PRIORITY=4 - /ON=WP2DV0::'WP2DV0_Start' WP2DV0_SINGLE $INITIALIZE/QUEUE/BATCH/JOB_LIMIT=5/BASE_PRIORITY=4 - /ON=WP2DV1::'WP2DV1_Start' WP2DV1_BATCH $INITIALIZE/QUEUE/BATCH/JOB_LIMIT=1/BASE_PRIORITY=4 - /ON=WP2DV1::'WP2DV1_Start' WP2DV1_SINGLE $INITIALIZE/QUEUE/BATCH/JOB_LIMIT=5/BASE_PRIORITY=4 - /ON=WSPAR2::'WSPAR2_Start' WSPAR2_BATCH $INITIALIZE/QUEUE/BATCH/JOB_LIMIT=1/BASE_PRIORITY=4 - /ON=WSPAR2::'WSPAR2_Start' WSPAR2_SINGLE $INITIALIZE/QUEUE/BATCH/JOB_LIMIT=2/BASE_PRIORITY=4 - /ON=WP2INF::'WP2INF_Start' WP2INF_BATCH $INITIALIZE/QUEUE/BATCH/JOB_LIMIT=1/BASE_PRIORITY=4 - /ON=WP2INF::'WP2INF_Start' WP2INF_SINGLE $INITIALIZE/QUEUE/BATCH/JOB_LIMIT=2/BASE_PRIORITY=4 - /ON=WFTINF::'WFTINF_Start' WFTINF_BATCH $INITIALIZE/QUEUE/BATCH/JOB_LIMIT=1/BASE_PRIORITY=4 - /ON=WFTINF::'WFTINF_Start' WFTINF_SINGLE $INITIALIZE/QUEUE/BATCH/JOB_LIMIT=2/BASE_PRIORITY=4 - VAX-17 PAGESWAPPER - November 1985 - Volume 7 Number 4 Heterogeneous VAX Clusters /ON=WFTCN0::'WFTCN0_Start' WFTCN0_BATCH $INITIALIZE/QUEUE/BATCH/JOB_LIMIT=1/BASE_PRIORITY=4 - /ON=WFTCN0::'WFTCN0_Start' WFTCN0_SINGLE $! $! Now do the cluster wide generic $! $ ASSIGN/SYS/EXEC 'Node'_BATCH FAST $ ASSIGN/SYS/EXEC 'Node'_SINGLE SYS$SINGLE $ ASSIGN/SYS/EXEC 'Node'_BATCH SYS$BATCH $ INITIALIZE/START/QUE/BATCH - /GENERIC=(WP2DV0_BATCH,WP2DV1_BATCH,WP2INF_BATCH) - SHARE_BATCH A bunch of batch queues!!! It is unfortunate and sad but true that each node in our VAXcluster needs its own pair of batch queues. Lemma to Rule 5 (taken without proof): Changes in logical names under VMS V4.0 may surprise you. We use group logical name tables extensively to make our process control software play correctly. Under version 3.x of VMS we did the old change UIC during SYSTARTUP.COM to get the tables all set up as follows: $ SET UIC [a,b] $ DEFINE /GROUP alog1 something $ DEFINE /GROUP alog2 somethingelse : : $ SET UIC [c,d] $ DEFINE /GROUP blog1 unique $ DEFINE /GROUP blog2 special : : This doesn't work on VMS 4.0! How to do it is well explained in the release notes so I won't reiterate in gory detail here. Essentially you create a command file with the commands to define the group logical names. Then during SYSTARTUP.COM, you submit this command file on behalf of a member of the group with GRPNAM privilege. We use this method. However, if you use generic batch queues, the job submitted may run on a machine other than the one on which you want the logicals to be defined. Therefore the submit must not only specify the user name of the group member to execute the command procedure, but the explicit batch queue in which to submit the job. Another part of the queue manager setup is that the queue manager must be explicitly started on every node in the cluster. The startup command allows one to specify where on the disk the shared queue file will be maintained. Since we already have one VAX-18 PAGESWAPPER - November 1985 - Volume 7 Number 4 Heterogeneous VAX Clusters disk mounted and in use by three of the systems, we decided to put the shared queue file on this disk. The following command appears in SYSTARTUP.COM for each system in the VAXcluster: $ START /QUEUE/MANAGER $1$DUA0:[CLUSMAN] This implies that earlier in the startup sequence $1$DUA0: has been mounted. We have defined $1$DUA0: as our quorum disk, so since we have to mount it to allow the queue stuff to work properly, we are really not giving the premise that the quorum disk does not have to be mounted a fair test. Corrollary to the Lemma to Rule 5: If you use temporary mailboxes to communicate among cooperating processes in a group, you'll find another surprise in VMS 4.0. The logical name for the mailbox is not put into the group logical name table automatically. The simplest solution to this problem is to put the following command in your SYSTARTUP.COM file. $ DEFINE/EXEC/TABLE=LNM$SYSTEM_DIRECTORY - LNM$TEMPORARY_MAILBOX LNM$GROUP This will force the temporary mailbox logical names to appear in the group logical name table as in previous versions of of VMS. Rule 6: The allocation class for disks on the HSC is set on the HSC, not in the VAX. Once you have this right, it seems clear that you could never have misunderstood how to do it. But... In initially trying to make all the disks attached to the dual HSC50's more available by assigning them to an allocation class, I had a real struggle trying to figure out how to specify the allocation class for the HSC disks. The command is in the HSC50 User's Guide, not in the Guide to VAXclusters as I had hoped. The way to set the allocation class for the HSC50 is to go to its typer and enter the following: ^C HSC50> RUN SETSHO SETSHO> SET ALLOCATE DISK n This will cause the HSC to know that it is in an allocation class. It is important that you let your field service engineers know that the allocation class is important. If they do a maintenance operation on the HSC50, the allocation class can 'get lost'. It must be reestablished for proper cluster operation. Rule 7: The distributed lock manager can provide some subtle surprises. I must state at the outset that I think the distributed lock manager is a superb software tool. It is the key to making clusters play. It works extremely well, so well in fact that it may be locking things you don't want locked. VAX-19 PAGESWAPPER - November 1985 - Volume 7 Number 4 Heterogeneous VAX Clusters In our field systems, we don't use clusters yet. The nodes in a field installation communicate via Ethernet but otherwise run relatively independently of one another. We use a lot of global sections to make data available to many tasks simultaneously. We also use the lock manager to assure the integrity of these global sections during update. Our naming convention for these global sections is common to all machines, and the name for the lock is the same as the name of the section. Therein lies the problem. In running our multinode system in the cluster, we discovered that if a global section is locked on any node in the cluster, sections with the same name are locked on other nodes of the cluster. This was a surprise at first, but is just a manifestation of how well the distributed lock manager does its job. Summary The heterogeneous VAXcluster can take on a variety of forms. It is hard to imagine the various ways in which VAXclusters will be applied to solving real world problems. I am certain that there are other pitfalls on the road to the implementation of a heterogeneous VAXcluster which we serendipitiously stepped over in getting ours to work. I hope the ones described here will allow you a quick and secure implementation of your heterogeneous VAXcluster. VAX-20 PAGESWAPPER - November 1985 - Volume 7 Number 4 Adjusting Working Set Parameters for Users Adjusting Working Set Parameters for Users AUTHOR: Allen A. Watson The Record Hackensack, NJ Preface To Pageswapper Version This document was first prepared for an in-house class on adjusting working set parameters. Only minimal editing has been done to prepare this for the DECUS Symposium Session Notes, so some references to purely local concerns may remain. Due to time constraints, the notes were not included in the Session Notes. At the request of numerous members of the audience, who received the talk very enthusiastically, I am submitting the notes to the Pageswapper for publication. --- THE AUTHOR CONCEPTS OF PARAMETER ADJUSTMENT Before we even begin looking at adjusting parameters, we need to understand why we are adjusting them, and what it is we are adjusting. In other words, before we change anything we want to have a ____ clear goal in mind. You have to have a clear view of the target in order to hit it, so our first question is, what are we trying to achieve? The second question is, what are the elements of the system that we can affect by adjusting parameters? What exactly is it that we are altering, and what effect does it have to adjust them? VAX-21 PAGESWAPPER - November 1985 - Volume 7 Number 4 Adjusting Working Set Parameters for Users Goals of Parameter Adjustment The primary purpose of parameter adjustment of any kind is to improve the performance of the operating system and of the ____ __ ___________ programs that run on it. But what is performance? And how do we know when it is improved? We are not looking at the performance of one computer versus another, the "This program runs faster on Brand X" type of thing. We want to make our system perform better with the same programs, given the CPU, memory and I/O system that we have. But how is better performance measured? Two Types of Performance Criteria Performance can be measured in two ways: responsiveness to interactive users, and overall throughput of the system. In the first case we are looking at how quickly the system responds to commands typed by a user. In the second case we are looking at the total amount of work produced by the system in terms of records processed, reports produced, and so on. What we have to understand at the start is this: the two __ ___ performance goals are mutually exclusive. That is, if you _______ _______________ __________ ____ _______ __ ___ _______ improve responsiveness, throughput will suffer; if you improve ___________ ______________ ____ _______ throughput, responsiveness will suffer. There is a certain middle ground where both are kind of OK, but if you tune to make a system maximally responsive, the throughput will be rotten; and if you tune to make a system produce as much as possible, the response times at the terminals will be terrible. It's like automobiles: you can have a tow truck (which can do lots of work) or a sports car (which is responsive), but you can't really have both. Tow trucks have lots of power -- you can tow a house trailer -- but not much speed or maneuverability. Sports cars are fast and can maneuver, but don't try to pull a truck out of the mud with one. You may lean to sports cars a bit, and buy a Camaro; its sporty, faster and more responsive than the tow truck, but it's no competition for ____ a real sports car. Or you may lean to having something "practical", and choose a pickup so you can do some light towing and still have a little speed when you need it. You might even pick a vehicle that can switch from 2-wheel to 4-wheel drive, so you can switch back and forth. All of those same kinds of ____ options are what face us in tuning a computer. What kind of performance do we want? VAX-22 PAGESWAPPER - November 1985 - Volume 7 Number 4 Adjusting Working Set Parameters for Users ___ It may not be clear why responsiveness and throughput are mutually exclusive, so let's think about it a minute. How do you make a computer produce the most work (throughput)? By keeping it busy 100% of the time. If the computer is idle, you are wasting resources. So the way to increase throughput is to emphasize having everything as busy as possible doing __________ something productive. Now, how responsive do you think a system like that will be to a user at a terminal? If everything is ______ busy all of the time, that user is always going to have to wait for the system to finish something before it can respond. We all know that when the system gets really busy, responsiveness suffers -- often greatly. How do you make a system always respond quickly to users? By ____ making sure that it is always idle at least part of the time, so that when a new user types in a command, there is memory, CPU time, and I/O capacity ready and waiting to serve him. How do you think a system like that will compare to one that is always 100% busy, in terms of throughput, in terms of total work accomplished? There is no question that a responsive system will always be less productive than a busy one, because not all of the resources are being used all of the time. The Kind of Performance We Want What we have to decide is, do we want our system to be responsive, or do we want it to be productive? Or do we want it somewhere in between? If so, do we want it to lean toward responsiveness, or toward productivity? At The Record we have what is really a dual environment. We have systems that require rapid response; all of the interactive systems such as Circulation, AR, and Layout fall into this category. We have far more complaints about slow response than we do about inability to get the work done overall. But we also have some large jobs that need to get a lot of work done in a short period of time; for these jobs (such as month-end processing) responsiveness is not a requirement, but throughput is. During the day, from 8 to 5, we want to emphasize responsiveness. During the night, and on weekends, we want to ___ ____ __ emphasize throughput. So in fact we really need two sets of ______ __________ system parameters for these two different types of systems. Weekdays from 8 to 5 we want 2 wheel drive and rapid response; at night and weekends we want 4-wheel drive to tow a heavy load. VAX-23 PAGESWAPPER - November 1985 - Volume 7 Number 4 Adjusting Working Set Parameters for Users Since most of the jobs needing throughput are batch jobs, we can accomplish this by giving batch jobs a different set of parameters. We can also set up the system so that two different sets of parameters are in effect, one for daytime interactive use, and one for nighttime batch processing. This session will not cover that aspect, but it should be considered if your environment corresponds to ours. Most of the initial tuning we do will be concentrating on improving the responsiveness of interactive processes during the weekdays. We want the system to respond as rapidly as possible, and to run the user's images as fast as possible. Only when the total load on the system approaches 100% do we want to start sacrificing responsiveness in order to get more work done. If we keep these goals in mind, I think the choices we make about how to adjust parameters will be clear. What are we adjusting? When we talk about adjusting parameters that affect the users _______ ___ ______ working set, we are dealing with memory. We are talking about how the user process is allowed to use memory. We aren't adjusting anything about I/O or CPU usage. Adjusting Memory-related Parameters The reason we concentrate first on memory is that memory is the key to the VMS system. We have far more control over the use of memory than we do over the use of either of the other two resources. There are some adjustments we could make in these other areas, and perhaps we will eventually, but by controlling the use of memory and making it efficient, we can actually affect the use of these other resources as well. A process that lacks memory is going to waste CPU time and I/O time doing more paging, re-reading things from disk, queueing up requests for this or that resource. VAX-24 PAGESWAPPER - November 1985 - Volume 7 Number 4 Adjusting Working Set Parameters for Users Physical memory and virtual memory Let's review how VMS uses physical memory, in the context of a single process. Suppose we have an image that requires 1000 pages of virtual memory. How many pages of physical memory does it need to execute most efficiently? If you said "1000", you are oversimplifying. Physical Usually Less Than Virtual VMS only loads pages of an image on demand. Suppose our image is divided evenly into 500 pages of code and 500 pages of memory. Suppose again that the first page of code only references the first page of data, the second page of code only references the second page of data, and so on, and that all 500 pages of code execute sequentially, or linearly, one after the other. In theory, then (ignoring system overhead), the image could run in two pages of physical memory! An image of 1000 virtual pages will require 1000 physical pages only if it is extremely unstructured in its code (lots of jumping around from one place to another) and references all its data randomly. ____ 1000 pages is the most physical memory such a process could require. In most cases, giving such a process 1000 pages of physical memory would be wasting memory. Physical Memory Needs Depend on Images The actual amount of physical memory required by a process will depend entirely on what images are run by the process. The amount of physical memory required by a certain image can only be determined by observation of actual performance of the image. To set working set parameters correctly we are going to have to observe each image in action. In fact, if we encounter images whose physical requirements come close to their virtual requirements for memory, we need to look at having that image rewritten for better efficiency. VAX-25 PAGESWAPPER - November 1985 - Volume 7 Number 4 Adjusting Working Set Parameters for Users Working Sets _______ ___ The term working set denotes the number of pages of physical memory that are allocated to a process in executing an image. To achieve maximum responsiveness, the ideal is for every process to have all the physical memory it needs at any given time, so that page faults (requests for sections of code or data that are not in memory) are at a minimum. That is, as much as is possible, when data or code is requested, we want it to be in the working set. So we need to find the largest image a user will run, and make his working set large enough to handle it. ______ On the other hand, we don't want the working set to always be at its largest point; that would waste memory when we run smaller applications. That's why VMS can adjust the size of the working set, depending on demand, within the contraints set by the working set parameters. Our goal in defining these parameters for a user is to set them in such a way that the working set is allowed to grow to the largest size the user will need, but normally is set to a smaller value for running small images; and there needs to be a mid-point established that will govern how much memory the user is allowed to have when memory is scarce. Page faults _____ _____ ___ _______ ____ Let's be clear about one thing: every image you execute will _____ ____ ______ cause page faults. The program has to be read into memory at least once! So if you have an image with a virtual size of 1000 pages, you are going to have a minimum of 1000 page faults if ___ ____ ___ __ you use all of the code and all of the data. The only way an _____ __ ____ ____ ______ __ _______ ___ ____ _____ __________ image is read into memory is through the page fault mechanism. VMS does not perform an "initial load" of the entire image. It loads the starting segment of the image and then waits to load the other parts until you, or the program, ask for them. Some page faults are inevitable. _______ ______ __ ____ Every image, therefore, has a certain minimum number of page ______ faults that are necessary to perform a certain sequence of actions. Even if you gave all of physical memory to the image, you could not reduce the number of page faults below that _____ number. You might be able to re-write the code of the image, making its execution more linear, for example, and so reduce the number of pages needed in memory at any given time (the working set), but if the code occupied the same amount of memory overall the number of page faults would not decrease. VAX-26 PAGESWAPPER - November 1985 - Volume 7 Number 4 Adjusting Working Set Parameters for Users As we look at a certain image in action, we have to determine _______ ______ __ ____ ______ what this minimum number of page faults is. Techniques for finding this number will be discussed later. Hard Faults and Soft Faults All page faults above that minimum number are undesirable, but not all of them are "nasty". The really costly page fault is a ____ ____ _____ hard page fault, one that forces the system to read the disk. __ ___ _______ There are several other kinds of page faults that do not require _______ ___ ____ ____ ______ reading the disk; these are known generally as soft faults. If a soft fault does not require reading information from disk, then where does it get it? From elsewhere in memory, of course. Even though a page is not in the Working Set of a process, it can still be memory resident in some other place. ______ _____ _____ One example of a soft fault is the Global Valid Fault. An image can be installed shared, so that sections of code can be shared by several users. The first user who invokes the image causes the hard faults required to read in the code. Once that code is in memory, when a second user comes along and wants to fault in a certain page, instead of reading it from disk again, the page that is already in memory is simply included in the user's working set. All it takes is a queue instruction to put the page into the Process Page Table. Another type of soft fault involves two lists maintained by VMS, the Free Page List and the Modified Page List. These two lists ____ _____ serve as a page cache for all the processes on the system. Suppose you have a working set quota of 100 pages and call for that 101st page. VMS is going to take the oldest page in your working set and tack it on to the end of the Free Page List, and then insert the new page 101 into your working set. VMS is smart enough, however, to remember that you once owned that page on the Free Page List. If you request that page again, instead of going back to disk for it, VMS just swipes it from the Free Page List and puts it back into your working set. All that is moved is a pointer to the page. The same thing can happen with pages you have modified, except they go onto the Modified Page List instead of the Free Page List. The page fault rate for the system as a whole can affect how efficiently this page caching works. If you are the only user on the system, then any page you drop from your working set will be waiting on either the FPL or the MPL when you next want it. If there lots of users on the system, however, they are going to be gobbling up pages off the top of the Free Page List, and your VAX-27 PAGESWAPPER - November 1985 - Volume 7 Number 4 Adjusting Working Set Parameters for Users used page is going to percolate to the top of the list eventually, at which time that physical page will be given to another user. If you now issue a request for that particular virtual page in your image, it is no longer mapped to a physical page; VMS will have to find another physical page from the FPL and read the data from disk again. The higher the overall page fault rate on the system, the faster pages will move through the FPL and "disappear" from memory. As you can see there are so many variables involved in memory management that tuning it is very complex; adjusting for one condition may throw something else off in an unexpected direction. We all will have to learn by experience. ____ ________ __ __ The main point of this section is that what concerns us is _________ ____ ____ ______ primarily hard page faults. Soft faults, in general, are cheap. We have to be aware, however, that what are soft faults on a lightly loaded system can easily turn into hard faults if the ___ ___ system gets busy. Therefore, we will tune to eliminate all but ___ _______ the minimum page faults if possible. If we can't do that, then we will tune down to where all, or most, of the extra faults are soft ones. In this stage of tuning it will be wise to run the ____ image on a busy system to see if the soft faults stay soft. AUTHORIZE Parameters There are three parameters that affect the working set of an individual process. These parameters are set using the AUTHORIZE program, and can be adjusted (within certain limits) on the fly by the SET WORKING_SET command. The three parameters are: WSDEFAULT (Working set default), WSQUOTA (Working Set Quota), and WSEXTENT (Working Set Extent). WSDEFAULT WSDEFAULT assigns the minimum amount of memory allocated to your process (no matter what image you execute). The normal DEC value for WSDEFAULT is 150 pages. This doesn't mean you automatically get 150 pages of physical memory. What it does mean is that your Process Page Table is given 150 slots into which information about a physical page can be stored. A page table slot is not large; setting aside the memory for your Process Page Table is generally not a costly waste of memory if you don't use all the slots. On the other hand, extending the VAX-28 PAGESWAPPER - November 1985 - Volume 7 Number 4 Adjusting Working Set Parameters for Users Process Page Table involves a fair amount of system overhead; so if you know that most images you run require more than 150 pages it could pay to make WSDEFAULT larger than 150. Conversely, any ____ pages you have that fit within your WSDEFAULT you will keep _______ ___ ____ ____ __ ___ whether you need them or not, so too big a WSDEFAULT could waste a lot of memory. For example, consider our extremely linear program above that used one page of data per page of code, one after the other. We said it could actually run in a working set (physical memory in use at one time) of 2 pages. But if WSDEFAULT is set to 150, the process will hold onto those early pages until 150 pages of physical memory are in use, and only when that limit is reached will the older pages start being re-used. (In actual practice a fair number of pages are used by system overhead, such as the Process Page Table itself.) So some processes that run only small images (images that need a small amount of memory at one time) could profit from having WSDEFAULT reduced, thus releasing more physical memory for use by other processes. (It isn't likely we will find this condition too often!) Our goal in setting WSDEFAULT should be to find a value that is large enough to allow many images to run without needing more memory, but not so large that lots of images are wasting memory by holding it when they don't need it. For instance, if once a week some user runs an image that always requires a minimum of ___ 300 pages, you would not set WSDEFAULT to 300; that would waste memory most of the week. But if the user runs that image more than half the time, setting WSDEFAULT to 300 makes sense. So you begin to see that to set these parameters for a user we ____ ______ have to know what images that user runs, and how frequently. WSQUOTA WSQUOTA is generally set higher than WSDEFAULT. WSQUOTA defines ______ _____ the normal limit to the growth of your working set. In normal circumstances, if the image you are running requires more memory than WSDEFAULT, VMS will let you grow unbounded up to the limit of WSQUOTA. The normal VMS value for WSQUOTA is 200 pages. This means that if your process needs more than 150 pages, VMS will always try to give it to you, up to a limit of 200 pages. When you request the 151st page, VMS will take a look at your WSQUOTA; if it is 200, VMS will automatically expand your Process Page Table to 200 slots, and will grant you the physical pages you are requesting. VAX-29 PAGESWAPPER - November 1985 - Volume 7 Number 4 Adjusting Working Set Parameters for Users If the system is memory poor, when someone else requests memory, WSQUOTA is the first limit to which your process can be trimmed down. (You can exceed WSQUOTA sometimes, and if you do, you can always be trimmed back to that limit if someone else needs memory.) WSQUOTA is normally set to a level where, once you have reached it, your process can run without page faulting, or with only soft faults. Our goal in setting WSQUOTA should be to determine a value where, given the images a process will run, no hard page faulting will occur for any frequently run image. (For very large images that are run infrequently, we will rely on WSEXTENT; however, WSQUOTA should still be set large enough that these infrequent images can run without excessive hard page faults in a working set of WSQUOTA size. Remember that on a loaded system, WSQUOTA will be the limit to the growth of the working set.) WSEXTENT ______ _____ WSEXTENT is like the credit limit for the process. If there is free physical memory in the system and you need it, WSEXTENT defines the limit to which VMS will loan you the physical memory. It's only a loan. As long as no one else needs it, you've got it, but if someone else comes along who needs it, VMS ________ will take it back from you (this is known as trimming your process). Making WSEXTENT as large as it needs to be is cost free. If a process needs memory, and the VAX has it, it will be granted. If the VAX doesn't have free memory to give, it won't be given. There are definitely users on our system who need to have WSEXTENT increased, so that they can get the memory they need when it is available. Check your system at a fairly busy time with SHOW MEMORY. If it shows more free memory than is specified in the SYSGEN parameter FREELIM, you are probably not making the most of your memory and could profit from increasing WSEXTENT for some of your users. If you have a limited amount of time to spend tuning, this is one of the quickest, easiest, safest, and most beneficial things you can do for your system. The DEC value for WSEXTENT is 500 pages. In many cases this is not enough. VAX-30 PAGESWAPPER - November 1985 - Volume 7 Number 4 Adjusting Working Set Parameters for Users When you have reached WSQUOTA and ask for more pages, VMS looks at the SYSGEN parameter BORROWLIM. If there are BORROWLIM pages left in the Free Page List, VMS will extend your Process Page Table to WSEXTENT slots, thus giving you a sort of credit limit extension. Then, it checks GROWLIM; if there are GROWLIM pages on the Free Page List, it actually reads in pages into your working set, usually 16 at a time (the value of 16 is another SYSGEN parameter, PFCDEFAULT; it can be altered in LINKing an image if the programmer knows another cluster size is more efficient). GROWLIM is usually smaller than BORROWLIM; on our system, BORROWLIM is set at 300, and GROWLIM is 63. These ____ parameters insure that there is usually some free memory available for processes that need it. The maximum value of any of the three user working set parameters is determined by a SYSGEN parameter, WSMAX. This is the largest working set that will be allowed on a VMS system; so we may need to take a look at increasing that value, so that we can set WSEXTENT large enough for some of our users. We may also need to adjust BORROWLIM and GROWLIM to correspond to the differences between WSQUOTA and WSEXTENT. _______ _____ Our goal in setting WSEXTENT is to find the largest image a user will run, and the smallest number of pages in which that image can run with no hard page faulting. By setting WSEXTENT to the number of pages required by a user's largest image, we insure that if physical memory is available, that user will get it. Setting the Parameters To set the working set parameters for a user, we have to know what images that user runs, how frequently they run them, and which image requires the most physical memory to run efficiently. Remember that normal DCL commands like SHOW run images; you have to consider those as well. For the most part, standard DCL commands will run efficiently within the setting used in the default account: 150, 200, and 500 for DEFAULT, QUOTA, and EXTENT. Application programs and foreign utilities like EMACS, PORTACALC, and such, may require much larger values. Start by determining the largest images the user runs. The size of the .EXE file on disk is a good rule of thumb; large .EXE files will be likely to need large working sets, although this is not always true. Select the three or four images that you think, based on file ____ size, may require a lot of memory. If you know a certain image uses lots of data areas (like text editors that read files into memory, or spreadsheets), include that in your list also. VAX-31 PAGESWAPPER - November 1985 - Volume 7 Number 4 Adjusting Working Set Parameters for Users Now, establish a test account. (Don't play with the actual user parameters on the fly!) Set all three parameters (WSDEFAULT, WSQUOTA, and WSEXTENT) to the same value for the account. Select a value large enough to insure that, other than initial loading of pages from the image, no page faulting will occur for what you think is the largest image run by the account. The _____ reason we set all three parameters to the same value is to force VMS to grant this process a large working set. I started with a value of 1000 pages for all three parameters; in some cases I found that even with this much memory some images still did a lot of hard faulting, and eventually, for a few users, wound up giving them a WSEXTENT value of 1300 pages. Log in to the account and do a SHOW PROCESS/ACCOUNTING, and note the peak working set size, the page fault value, and the amount of CPU time used so far. Run the image you think will need the most memory, and do a "standard run"; that is, do what you think will need the most memory, and keep a record of what you do so you can repeat it later. Now do a SHOW PROC/ACC again. You should see a larger peak working set and an increase in the page fault value. Note the difference between the old page fault value and the new one; this is the number of page faults caused by the image you ran. Also note the difference in the amount of CPU time used; this is what was consumed by the image you ran. ____ _______ ___ ____ If the peak working set size is equal to the value you set for all the WS parameters, the value was not large enough; increase it and try again. Note that for this testing to avoid impacting other users, it should be run on the system when there is lots of free memory available. If the peak working set size is smaller than the value you chose, drop the parameters to that value and re-run the image, using this peak value as your starting point. After you have determined the peak working set needed for an image, start cutting the value of all three parameters down by about 1/10 of the maximum value. If you started at 500 pages, drop down to 450 for all three parameters. Run the image again, and record the same three figures. If there is no change at all: same amount of CPU time, same number of page faults, and same peak working set size, you still have plenty of memory, so cut the value down again. Before long, you are going to start seeing an increase in the number of page faults, and also an increase in CPU time used. Write down the numbers, but don't stop here; using smaller decrements (about half what you have been using till now), decrease the working set parameters again, and do another run. VAX-32 PAGESWAPPER - November 1985 - Volume 7 Number 4 Adjusting Working Set Parameters for Users Each time you drop down the working set size, you will see a small increase in page faulting and in CPU time. Eventually, CPU time will jump markedly up, as the system starts spending most of its time managing memory for you instead of running your image. There may be a moderate jump in CPU time somewhere in the middle, so when you see the first big jump, drop down at least once more to see if you have bottomed out yet. If the next increase is minor, keep on dropping till you get another big jump. When you are done, you will have a set of values starting from best performance to worst performance. WSEXTENT is easy to set: set it at the value needed for best performance (no page faults above the minimum required to read in the image). To set the other values it may help to draw a little graph, plotting CPU time against page fault rate. ____ _____ Setting WSDEFAULT is also fairly easy; set it just above the bottom rate where CPU time starts to climb out of sight. To set WSQUOTA, find a place in the middle where the image seems to run OK, with some page faulting above minimum happening, but not too much CPU time being consumed in overhead. Compare the value you choose for WSQUOTA with the value of Peak Working Set; if the Peak value is significantly greater you may want to increase WSQUOTA a bit because those extra pages the image uses are going to cause hard faults if memory is scarce and the process is limited to WSQUOTA size. To be sure you have set WSQUOTA correctly you must run the image with these values twice, once with memory plentiful, and once with memory scarce. Both times, doing identical runs, note the number of Direct I/O's before and after running, and take the difference between the starting and ending values. This will be the number of I/O's done during the run. The difference between the number of I/O's when memory is plentiful and the number when memory is scarce will represent the hard page faults that occurred when memory was scarce. If the number is greater than two per second for the clock time of the run, increase WSQUOTA a bit and try again. _ If that sounds like a lot of work it is, and it is all for a ______ _____ single image. Now, you have to repeat the process for the other large images run by this user. To do a completely thorough job, you should build up a table of recommended working set parameters for every image run on your system. When you add a new image (i.e. write or buy new software) you go through the exercise again and add it to your table. Then when you are setting up an account for a new user, all you have to do is consult the table and extract the set of images he will be running. VAX-33 PAGESWAPPER - November 1985 - Volume 7 Number 4 Adjusting Working Set Parameters for Users If you are mainly concerned with setting WSEXTENT properly, just do this for the larger images on your system. After you have determined the values for the set of images run by a user, you can set his working set parameters with ___ AUTHORIZE. Set WSEXTENT to the largest value required by any of the images. WSQUOTA, likewise, should be set to the largest _________ ___ value required by any image that is regularly run by the user. ___ ______ ___ ____ ___ ___ (For WSEXTENT you take all images the user may run into account; _________ for WSQUOTA, just consider the ones he runs regularly.) ____ WSDEFAULT should be set to the mean value of what you determine as WSDEFAULT for each of the images. WHAT A MEAN VALUE IS ____ A mean is the point halfway between the largest and smallest of a set of values. For example, if you have four processes for which WSDEFAULT could comfortably be 100 pages, and one for which 200 pages is required, the mean value will be 150. Just take the largest and smallest numbers and divide by 2. The result is the mean. One of the DECUS attendees told me that what I ______ have defined above is the median rather than the ____ _______ mean, which he says is identical to the average. Fine, the formula stands. It isn't an absolute formula, either. If you have a heavy preponderance of images toward the top end of the range and one or two very small ones, you would probably be better off using the average value to favor the larger images. The "mean" as I describe it gives a good broad brush rule; fine tuning has to be by the seat of the pants, based on observation of actual performance. You have now finished determining working set parameters for a single user. If there are other user accounts that run the same set of programs, set their parameters the same way. SYSGEN parameters. SYSGEN parameters affect every user on the system, so for the purposes of better control I suggest you have all SYSGEN parameter changes funnelled through a single system manager. VAX-34 PAGESWAPPER - November 1985 - Volume 7 Number 4 Adjusting Working Set Parameters for Users There are several parameters that may be affected by your efforts. Each is discussed briefly in the sections that follow for what it does, and why we might need to change it. WSMAX The maximum value of any working set on the system. If anyone determines that a user needs a very large WSEXTENT value, he should compare it with the current value of WSMAX to make sure WSMAX is not exceeded. If WSMAX is exceeded by your calculated value, you may want to suggest that WSMAX be increased. In any case, WSMAX can be no larger than the total pages available on your system for user memory, that is, total pages of memory less pages permanently allocated to VMS (see last line of SHOW MEMORY display). BORROWLIM The number of pages that must be on the Free Page List for the system to authorize growth above WSQUOTA for any process. This is not likely to change from its default value as determined by AUTOGEN.COM. If you want to keep a larger Free Page List around to increase the liklihood of soft faults instead of hard faults, you could increase this parameter. This will tend to increase swapping, however, on a busy system. GROWLIM The number of pages that must be on the Free Page List for an actual loan of pages to occur. Loans are given in amounts of 16 pages at a time, so the current GROWLIM of 63 is probably OK. Again, if you want to keep a large FPL, you could increase this. Increasing either BORROWLIM or GROWLIM on a memory poor system will have the effect of increasing swapping, so this could be undesirable. VAX-35 PAGESWAPPER - November 1985 - Volume 7 Number 4 Adjusting Working Set Parameters for Users PFCDEFAULT Page Fault Cluster Default, normally 16. Defines the number of pages read from disk when a hard fault occurs. If you fault on one page, VMS will read in PFCDEFAULT pages from your image file (or the Page File). DEC does not advise setting this below 16; however, in actual observation most images on our system fault in only about 6 pages per page fault read due to program sections, etc. Probably best not to mess with this one; if you have images that tend to be non-linear in execution, you can ___ ____ _____ reduce the cluster factor for that image with a qualifier on the LINK command. Editor's Workfile by Larry Kilgallen, Pageswapper Editor All INSTALLs are not equal (or even compatible)- Yes, I know, it says so in the "Technical Changes" section of the VMS V4.0 INSTALL documentation, but I like to think it might have escaped someone else's attention besides my own. Although everyone has to switch to the new INSTALL syntax before the next major version of VMS, you can NOT have various privileged users switch at various times. The two syntaxes really produce different results, and it is possible to install an image with one syntax and not be able to disinstall it with the other. It is possible to install two different versions of the same image with the two syntaxes. I have seen it happen and I was all set to SPR it until I discovered it is not a bug but a feature (?) So just like overlapping edits on SYSTARTUP, all those who do installs on a given system should COORDINATE their activities, and in particular the date on which they (and their startup command procedures) switch to the new syntax. Obtaining VAX Pascal documentation - Well, my order from the DEC Electronic Store did not go entirely unnoticed; I got an acknowledgement of my July 10 order dated July 31. Nothing came during August, so on September 9 they got a letter of inquiry from me via certified mail. It is now September 29, and there is no response as yet. Stay tuned... VAX-36 PAGESWAPPER - November 1985 - Volume 7 Number 4 Notes from the European Symposium Notes from the European Symposium by Larry Kilgallen What follows is a list of "miscellaneous" information I picked up at the European DECUS Symposium in September which has not been covered earlier in this newsletter. Some of this may be familiar to readers from the Spring US symposium, but I for one have not gotten that far in listening to the cassette tapes. VMS Source Kits As of the Symposium (September) the VMS developers were busy putting together an UPDATED SOURCE KIT (applause please) for VMS version 4.2 (sic). The non-developer types apparently are just as busy figuring out what the distribution policy for same is to be. HSC50 V250 software went to SDC on September 6. HSCnn The goals driving the next model HSC to be released are a faster boot (non-TU58) and greater connectivity (more drives) rather than greater throughput. The design phase of that product is long gone, but at least in September developers were still taking input for models after the next one. $GETQUI The "context" retained by $GETQUI for a process is not kept in that process but rather is kept in the job controller. The mechanism for passing information back to the requesting process VAX-37 PAGESWAPPER - November 1985 - Volume 7 Number 4 Notes from the European Symposium takes no notice of the image count in the process header, so any caller of $GETQUI is vulnerable to a context left over from a previous image being abnormally terminated (or coded wrong). The recommendation is that any program using the $GETQUI service should make its first call to $GETQUI be a context clear. TMSCP The TMSCP protocol used with TA78s (and Tx81 for that matter) does not support byte swap, so a user converting to TA78s may find some formerly working programs fail. VMS/SNA This is a new software product for hanging your MicroVAX on an SNA network. The user interface is the same as for the SNA/Gateway access routines. The official party line to explain the difference between VMS/SNA and the SNA/Gateway is that VMS/SNA is for connecting a single DEC machine to an IBM network while the SNA gateway os for connecting a DEC network to an IBM network. (There are bound to be internal differences since PDP-11 object code does not port well to the MicroVAX.) DEC representatives under questioning admit that the only reasons why VMS/SNA is not available for MacroVAXen are marketing reasons. SNA/Gateway loading limits Estimate are that with a 56 kb line to the SNA network, the DEC SNA Gateway can keep the line about 70% busy, except for a workload composed entirely of the RJE product where the figure is 40%. The difference is that the RJE product does more processing inside the gateway itself, and the PDP-11 in there runs out of steam. In considering a new processor for SNA Gateway work, DEC folks indicate their ultimate goal would be a "32-bit" processor rather than plugging in a faster PDP-11. They didn't specifically promise a VAX, but neither did they have warm feelings about the glories of RISC architecture. A 4300 seems unlikely. VAX-38 PAGESWAPPER - November 1985 - Volume 7 Number 4 Notes from the European Symposium SNA Gateway and FMS Some fallout of the VAX BTS (bi-sync) support in FMS is that those logging into a VMS machine from their IBM machine through DHCF get FMS support within the limits of what an IBM 3278 terminal will do (e.g., no scrolling). This is important, since most VMS screen activities are NOT supported. I presume those who are interested (or DEC) could write their own foreign terminal support for the 3278. I notice comments in the VMS V4.2 microfiche that hooks have been provided for TPU to use SMG someday. Herbert Grosch on Artificial Intelligence This computer pioneer was keynote speaker and after his talk was asked by a member of the audience to comment on the recent emergence of Artificial Intelligence. His comment: "The part that is good [expert systems] is not new and the part that is new is not good." Peter Bendall on VAX SIG Business Meetings The European VAX SIG chair does not result to trickery like announcing prize winners at the business meeting, and it shows (in the attendance). Peter's idea for a VAX SIG business meeting is "Thank you both for coming". Differences from US Symposia This was my first non-US DECUS Symposium, and in restrospect it seems like the only one that has been "different". The committee involved is a different set of people as is the DECUS staff involved. There is some sense of time warp involved as the 2000 or so attending used some mechanisms (separate lunch tickets) that those at US symposia used when the crowds were smaller. VAX-39 PAGESWAPPER - November 1985 - Volume 7 Number 4 Notes from the European Symposium The exhibit area was actually set up for a DEC trade show called DECville the previous week (much as DECtown or DECworld in Boston years past). Most brochures were available only by asking for them at the DECville "library". There was a rather cumbersome lineup for a couple of browsing terminals (until someone brought out some mimeographed literature lists which worked just as well). The curious result of all this was that the exhibit area came across as much LESS commercial (good in my opinion) than what I have seen in the US. In the sessions commercialism problems were a lot more like those at US Symposia with DEC marketeers droning on about the history of VAX processors (this may come as a surprise to our readers, but a VAX 8600 has about four times the CPU power of a 780). The crowds at the European symposium were MUCH more polite (less demanding) than at US symposia. There was little in the way of redirect from questioners, no fury about things DEC had done or left undone, and developers were even allowed to procede through the halls to lunch. It may be the language barrier (English was the language of the symposium but not the native tongue of all those attending), it may be the fact that the crowd in Europe only gathers once a year, or it may be that Europeans are just naturally more polite. VAX-40 PAGESWAPPER - November 1985 - Volume 7 Number 4 VAX System SIG Committee List VAX System SIG Committee List As of July 23, 1985 Osman K. Ahmad - TOPS-VAX Association of American Railroads Technical Center, Research and Test Department 3140 South Federal Street Chicago, IL 60616 Joe Angelico - Assistant Symposium Coordinator US Coast Guard CCGD8(DT) Hale Boggs Federal Building 500 Camp Street, New Orleans, LA 70130 Elizabeth Bailey - Volunteer Coordinator 222 CEB Tennessee Valley Authority Muscle Shoals, AL 35660 June Baker - Planning Computer Sciences Corporation 6565 Arlington Boulevard Falls Church, VA 22046 Joe L. Bingham - Librarian Mantech International 2320 Mill Road Alexandria, VA 22314 Bob Boyd - Commercial GE Microelectronics Center MS 2P-04 Post Office Box 13409 Research Triangle Park, NC 27709 C. Doug Brown - Security Sandia Labs P.O. Box 2644 Albuquerque, NM 87185 Jack Cundiff - Assistant Symposium Coordinator Horry-Georgetown Post Office Box 1966 Conway, SC 29526 Tom Danforth - Handout Editor Woods Hole Oceanographic Institute Woods Hole, MA 02543 VAX-41 PAGESWAPPER - November 1985 - Volume 7 Number 4 VAX System SIG Committee List Jim Downward - Migration and Host Development, VAXintosh KMS Fusion Incorporated 3941 Research Park Drive Ann Arbor MI 48106 Jane Furze - Campground 3830 West Cochise Phoenix, AZ 85064 Dennis Frayne - Real Time/Process Control McDonnell Douglas 5301 Bolsa Avenue Huntington Beach, CA 92646 Carl E. Friedberg - Internals In House Systems 165 William Street New York, NY 10038 Don Golden - Publications Coordinator c/o Shell Development Company, D-2132 Westhollow Research Center Post Office Box 13480 Houston, TX 77001 Gary Grebus - System Improvement Request Battelle Columbis Labs Room 11-6011 505 King Avenue Columbus, OH 43201-2693 B. Hancock - Network Dimension Data Systems, Incorporated 2510 Limestone Lane Garland, TX 75040 Jeffrey S. Jalbert - Historian J C C Post Office Box 381 Granville, OH 43023 614-587-0157 Ken Johnson - VAXcluster Working Group Meridian Technology Corporation Post Office Box 2006 St. Louis, MO 63011 Ray Kaplan - VAXeln Pivotal Incorporated 6892 East Dorado Court Ticson, AZ 85715 VAX-42 PAGESWAPPER - November 1985 - Volume 7 Number 4 VAX System SIG Committee List Lawrence J. Kilgallen - Newsletter Editor Box 81, MIT Station Cambridge, MA 02139-0901 Margaret Knox - Chair Computation Center University of Texas Austin, Texas 78712 Ross W. Miller - Vice Chair and Working Group Coordinator Online Data Processing, Inc. N 637 Hamilton Spokane, WA 99202 Eugene Pal - Multiprocessor US Army CAORA (ATOR-CAT-C) Fort Leavenworth, KA Thomas Provost - Hardware MIT/LNS Bates Linac Facility Post Office Box 846 Middleton, MA 01949 Susan Rehse - System Management Lockheed Missiles 3251 Hanover Street Palo Alto, CA 94301-1187 Bob Robbins - Advisor Array Computer Consultants 5364 Woodvale Drive Sarasota, FL 33582 Larry Robertson - Real Time/Process Control Bear Computer Systems Inc. 5651 Case Avenue North Hollywood, CA David Schmidt - LUG Coordinator Management Sciences Associates 5100 Centre Avenue Pittsburgh, PA 15232 Al Siegel - Advisor Battelle Memorial Institute 505 King Avenue Columbus, OH 43201-2693 D. Slater - Artificial Intelligence Institute for Defense Analysis 1801 North Beavregard Street Alexandria, VA 22314 VAX-43 PAGESWAPPER - November 1985 - Volume 7 Number 4 INPUT/OUTPUT INPUT/OUTPUT A SIG Information Interchange A form for INPUT/OUTPUT submissions is available at the back of the issue. INPUT/OUTPUT 466 Caption: Foreign Host Interfaces/Terminal Support Message: We are currently using an Intergraph VAX-11/751 for Municipal/County Mapping and Engineering applications. Our primary business data processing system is a WANG VS-100. We have 60 Wang PCs used for professional productivity applications and as terminals on the VS; a few are also used as (VT100) terminals on our VAX-11/751. The central processors are in the same room. We are looking for system interfaces/software functions which would provide the following functionality: file transfer between hosts; program access to data on either system, graphics output support for WANG PCs, anything else that is interesting from a similar site. Contact: Ian Caesar, Systems Support Corporate Systems Department The District of Surrey 14245 - 56th Avenue Surrey, B.C. Canada V3W 1J2 Telephone (604) 591-4406 Date: August 28, 1985 VAX-44 PAGESWAPPER - November 1985 - Volume 7 Number 4 INPUT/OUTPUT INPUT/OUTPUT 467 Caption: Sharing a TS11 between VAXes - Reply to I/O # 358 & 392 Message: We have developed an electronic linedriver and multiplexer for sharing a TS11 between two or more VAX processors. This allows us to connect remote (up to 300 feet) VAXes to a TS11. Also included is a reset circuit to reset the TS11 via the internal reset switch. Our solution also avoids a suspected problem under VMS 4.0, rebooting being necessary when using a mechanical switch or cable-swapping. Contact: Mr. Morten Christiansen ELAB (Electronics Research Laboratory) N-7034 Trondheim - NTH Norway Telephone +477 592679 (remember the time difference !) Date: August 28, 1985 INPUT/OUTPUT 468 Caption: Need to put DLV-11J on MicroVAX II Message: I need to put a DLV-11J on a MicroVAX II. When I install the board on the machine, I get an error message as the system is loading. The message indicates DDDRIVER.EXE could not be found. Does anyone have a driver for this device? Contact: Ken Levitt Informed Computer Solutions, Incorporated 9 Linn Lane Wayland, MA 01778 Telephone (617) 237-7427 Date: September 16, 1985 VAX-45 PAGESWAPPER - November 1985 - Volume 7 Number 4 INPUT/OUTPUT Submission Form INPUT/OUTPUT Submission Form A SIG Information Interchange Please reprint in the next issue of the Pageswapper If this is a reply to a previous I/O, which number? ________ Caption: ______________________________________________________ Message: ______________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ Contact: Name _______________________________________________________ Address ____________________________________________________ ____________________________________________________________ ____________________________________________________________ ____________________________________________________________ Telephone ____________________________ Signature _____________________________ Date ________________ Mail this form to: Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station, Cambridge, MA 02139-0901, USA PAGESWAPPER - November 1985 - Volume 7 Number 4 INPUT/OUTPUT Submission Form Tear out to submit an I/O item Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station Cambridge, MA 02139-0901 USA PAGESWAPPER - November 1985 - Volume 7 Number 4 System Improvement Request Submission Form System Improvement Request Submission Form Page 1 of _____ ________________________________________________________________ Submittor: Firm: Address: Phone: ________________________________________________________________ How to write an SIR: Describe the capability you would like to see available on VAX systems. Be as specific as possible. Please don't assume we know how it's done on the XYZ system. Justify why the capability would be useful and give an example of its use. If you wish, suggest a possible implementation of your request. ________________________________________________________________ Abstract (Please limit to four lines): ________________________________________________________________ Description and examples (use additional pages if required) PAGESWAPPER - November 1985 - Volume 7 Number 4 System Improvement Request Submission Form Tear out to submit an SIR Gary L. Grebus Battelle Columbus Laboratories Room 11-6011 505 King Avenue Columbus, Ohio 43201-2693 USA