From: HENRY::IN%"linscomb%NGP.UTEXAS.EDU%SRI-KL.ARPA%relay.cs.net@rca.com" 5-NOV-1986 11:43 To: info-vax@SRI-KL.ARPA Subj: DECUS trip report 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