linscomb@NGP.UTEXAS.EDU (Thomas J. Linscomb) (11/05/86)
From: Thomas Linscomb
Subject: Fall DECUS U.S. Symposium
San Francisco, October 5 - 10, 1986
Sessions Attended
V102 - VAX System Update
V099 - VMS System Update
V158 - VAX SIG Working Group Meeting
V178 - VAXCluster Working Group Meeting (acting as WG chair)
E016 - Printing Across DECNet
V056 - VAXCluster Extension Overview
V095 - Low end VAXCluster Performance
V053 - VAXCluster Internals (Network Interconnect)
V096 - Managing VAXClusters for Performance (chaired)
V081 - Using VAXClusters Effectively
DA059- ADV-11D Device Driver
V109 - Ins and Outs of VMS Sharable Images
V060 - Network File System
V062 - VMS File System Internals
V164 - System Improvement Request Response
V200 - Licensing Birds of a Feather meeting
Nashville Planning Meeting
V161 - VAX Advanced Question and Answer
Synopsis:
Since Marg has already covered the licensing issues in her report
I have not repeated the material here. Most of what follows is purely
technical VAX/VMS. Digital did not release any new hardware during
this session (except the VAXMate). The two software products that
were new included RSM, a remote system management tool, and a product
for managing the performance on large VAXClusters. This last
pre-product announcement was made under a cryptically hidden session
title.
I am now co-Chairing the VAXCluster Working Group along with the
previous Chairman. I intend to exercise the lines of communication
within the working group by having a few newsletters before the next
symposium. Digital's product direction continues to be heavily
towards the VAXCluster in its various forms and this group needs to be
active in directing that functionality. Jim Caddick, who is the other
chairman, will be addressing the problem in VAXClusters of each member
maintaining a different system time, while I am going to try and get
the VAXCluster System Journal "QUORUM" improved.
Odds and Ends:
VMS v4.5 will be a maintenance release only. It consists of 150
changes to 110 components. The kit has been turned over to SDC. It
includes limited dual porting of TA78 tapes (the tape must be
dismounted/mounted). VMS v4.6 will probably be a maintenance release
also.
The next major release (VMS v5.0?) is functionally complete/defined.
VMS v4.3 has been certified at C2 security level by the Department of
Defense. An interesting note is that Digital is working on an A1
certified machine (not necessarily of VAX architecture).
Digital made an advance statement informing users of UIS, the Work
Station software, that future developments in the software may require
changes to the UIS standard. Digital is attempting to give a large
warning that they are developing a common windowing interface across
different computer architectures (PC, VAXStation, etc).
The general VAXCluster performance session sought to explain some of
the cluster workings and debunk a few of the myths that have arisen.
A few of the MYTHS:
- CI bandwidth is often a limiting factor in clusters
- Locally attached disks perform better than globally accessible HSC
disks
- Tuning disk usage isn't terribly important
- Distributed locking is a major overhead in a VAXCluster
- If the quorum disk holds the majority of the votes in the cluster,
then the cluster can survive the loss of all but one VAX node
- Every cluster needs a quorum disk to prevent interruptions in
service
- Because the CI is a 70 Mb/s bus, it supports higher performance
DECnet traffic than a 10 Mb/s Ethernet.
- The VAXCluster concept is inseparable from the CI bus
This session is in the VAX Session Notes (V081). Anyone who wishes to
see the reason the above ideas are myths can contact me to get the
notes.
Also explained during this session were the VAXCluster state
transitions. Many users have complained that a transition will hang
the entire cluster for a very long time (10 minutes). The developers
have yet to explain how this can occur and appear skeptical that it
does.
I also brought back a handout from the "Ins and Outs of VMS Sharable
Images." This session gave some hints and undocumented information.
The SUN Network File System (NFS) was discussed under a number of VAX
sessions. The session I attended was very well attended.
The SIR session addressed the top ten requests of the VAX SIG. A few
notes:
- Some of the TOPS-20 MM (mailer) functionality will be incorporated
into VMS MAIL.
- More consideration to allowing privileged users to advise other
terminal users.
- Will implement a function to flush the command recall buffer
(RECALL/ERASE).
Overall the answers seemed to be a bit on the light side. Twice
Digital tried to get away with questioning the need for the
improvements. The speaker was reminded that the users had voted these
items as their top requests.
The VMS Question and Answer session posed problems to the VMS
developers. They ranged from the trivial to the unsolvable. Some
interesting points:
- $ SET ACCOUNTING/NEW can turn off accounting
- MicroVMS (v4.2 and v4.3) kitbuild doesn't build a MicroVMS kit.
Will not be fixed since MicroVMS will be rolled into VMS.
- April 17, 1987 is a special date. During a power failure some VAX
consoles will set the time to that date.
- For the VAX 8600 there is a grounding FCO. It consists of a half
inch braid to ground the BA11 Unibus box to the cabinet.
- For three high RA81 cabinets there is an FCO to remove the filter on
the top RA81. This relieves a large heat buildup in the top drive.
- XQP (the VMS file system) means eXempt from Quality control
Procedures
- There is a problem with the XEDRIVER on the 8600 that causes some
systems to be REALLY "slow". A fix exists and Denver has it.
MicroVAX Clusters:
The VAXCluster Extension Overview more clearly laid out Digital's
implementation of the VAXCluster concept based on the Network
Interconnect (NI or Ethernet). The MicroVAX Cluster had been shown as
a "technology demonstration", but it should come to market as a
layered product before the next DECUS meeting. I attended three
one-hour sessions covering the technology, performance and internals.
The MicroVAX Cluster consists of one boot member of any type of VAX
and up to thirteen MicroVAXs or VAXStations as satellites. Because of
the booting firmware required, the system is designed to work only
with MicroVAXs as the satellites. The total number of systems is
currently limited by the number of system roots.
The MicroVAX Cluster is based on Ethernet and does not allow any of
the members to have a CI (Computer Interconnect). This means that the
MicroVAX Cluster cannot have access to an HSC disk controller or
larger (CI based) VAXCluster. Undoubtably Digital is working on a
system to integrate both the CI and NI Clusters (maybe by using
hardware). Creating an ethernet interface for the HSC disk controller
has been ruled out.
An elaborate system has been setup to allow a MicroVAX that does not
have a disk to boot off the Ethernet. Multiple clusters can run on a
single NI without saturation or interference. The boot process uses
the Maintenance Operation Protocol to determine its boot host and a
password system to prevent illegal cluster members or local system
disks. The best MicroVAX configuration for the satellite member
should have a local disk for doing paging and swapping.
The internals of the NI cluster are very interesting. For the most
part it consists of replacing the CI port driver (PADRIVER) and the CI
hardware capabilities with a software driver for ethernet (PEDRIVER).
Schematically, if you look at the VMS system the higher functions (RMS
for example) do not know about the lower level communication systems
or hardware. Of course, the CI hardware provides many assists to the
software that had to be implemented in the software driver for
ethernet. Looking at the assists the CI provides, its easy to believe
that Digital is working on similar NI based hardware.
The performance data presented indicated that the satellite systems
should perform well, about the same as comparable systems based on the
current local disk technology. What must be remembered is that remote
disks only effects I/O. During heavy compute cycles, there is no I/O
dependency.
The best boot member in a MicroVAX cluster is a MicroVAX II with RA81
disks. It tends to run out of CPU power, ethernet interface
throughput and disk throughput at the same time. The MV II CPU is
faster then the VAX 11/780 (for the instructions used), it has faster
memory, and the VAX 11/780's memory cache doesn't help. The worst
satellite member would be a VAX 11/750 (not counting the "defunct"
11/730 and 11/725). The 11/750 does not provide enough I/O
throughput.
Avoid a DEUNA interface on the boot member, it does not provide enough
throughput. (AGL has recently purchased a DELUA interface to connect
to its MicroVAXs.)
--------------------
--Thomas Linscomb aka linscomb@ngp.UTEXAS.EDU aka t.linscomb@agl.UTEXAS.EDU
--Advanced Graphics Lab/Computation Center/The University of Texas
--Austin, TX 78712 phone: 512/471-3241
--uucp: ...seismo!ut-sally!ut-ngp!linscomb linscomb@ut-ngp.UUCP
--bitnet: cctj001@utadnx