Evaluation of WH14 SUN Management Needs
Evaluation of WH14 SUN Management Needs
D.S. Baddorf
The configuration of SUN workstations on the 14th floor has been evolving. Two more SUNs will soon be added, to make a total of 3 SUN workstations. Jim has spent some time planning a disk configuration for the three. Each SUN's local disk will have its own copy of the operating system. This is for speed. Each disk will also have a ``user files'' area. This area will consist of those user files actually located on the local disk, plus a pointer link to a similar tree of user files on the other two workstations' local disks. This is conceptually similar to the multiple user disks WARNER uses, which are mounted on different nodes but equally accessible to all. The CAD/VLSI software is not copied to each disk (except for one part pertaining to plotting). It is remotely accessed from the one disk which actually has the copy.
A possible future configuration might involve a file-server node. All the user files would then reside on this extra computer. Each workstation would still have its own copy of the operating system (unlike WARNER) for speed considerations. This configuration calls the workstation nodes ``dataless'' rather than ``diskless'' since they do retain a disk and a copy of the operating system. (The vaxstation nodes on WARNER are considered diskless, though they do have local paging and swapping files.)
Adding new nodes to the system requires hardware time (to get cables and disk drives installed), and about 2 hours to run the installation procedure menu for the SUN OS operating system.
Only Jim (and the new manager) has system privileges, or access to alter these system files.
This includes the core piece, MAGIC, a VLSI design tool. It also includes several tools for use with MAGIC.
A VLSI design schematic capture toolset which is based on the MAGIC package.
A silicon compiler.
The University of Washington Toolset. This includes GEMINI, which compares schematics, plus other pieces.
A simulator. This is a form of the familiar SPICE package. The HSPLOT piece is copied to all workstation disks, for speed of use.
Configuration of these packages has a user account being created for each package, with the name of the package as the username. Jim (or the manager) logs into these accounts to upgrade the software; no one else logs into these accounts or has write access to them. Any shared file templates or script/command files for using the tools is put into these accounts, and jointly used from there.
Jim suggests that installation and local modifications/improvements to these packages stay the responsibility of his group (him). These packages require a knowledgeable user for installation, and for any local improvement work. Jim estimates that half of his current 25% ``administrative'' time is actually spent here. This would include writing small command files to make the packages easier to use, to enhance batch work, etc.
This area of the management certainly would be easiest if left to the group which uses the packages, since any one else would have to become moderately proficient in their use before management would be effective. However, a manager who handles these packages too could more effectively assess the whole system, since the grasp of the whole picture would be improved. It would require more management time, both to learn the tools and to then manage them. Another consideration is that there should be some backup for Jim's expertise in managing the CAD packages, as well as the UNIX.
UNIX operating system and HSPICE have yearly software maintenance contracts (probably much simpler than the DEC contracts in which I have to itemize each product and node). These supply telephone support of ``How do I do this?'' sort of questions. According to Jim, they haven't ever run into a ``this is broken'' sort of question about software, so there has been no bug-fix tracking involved.
Currently it takes 2 hours to back up the user area of disk on the existing one machine. When there are three machines, and when the disks begin to be equally full, it would take about 6 hours to backup the user areas. There will be only one tape drive for the three nodes. This could be done every night, in the middle of the night, to increase the backup security without much more work.
This backup does not currently include the operating system files. If OS files don't change very often, perhaps OS backups could be infrequent. I would still suggest at least a weekly backup of the OS area.
There are currently about 5 people to be supported in this SUN user community. They will share the three workstations. Many are new to UNIX (since Jim has the current workstation, he has gained the most experience) and will take up a manager's time with questions and consultation. There are also CAD program questions to be fielded, though these might stay within the group unless the manager gets involved in the CAD software in depth. There is good (according to Jim) documentation for all the software, though users always have questions anyway.
Jim estimates currently he spends one afternoon per week on ``consultations'', with about half of this going to UNIX questions and half to CAD questions. This will continue to increase for a while, then probably start to decline as the group becomes familiar with the software. This will be affected by any hirings/retirings within the group, as well as any increase in the numbers of users.
I don't have a good feeling for the size of this laboratory section, and thus the potential for expansion of usage of the SUN workstations. However, once the initial group is doing ``good stuff'' with their workstations, other people will almost certainly want accounts and/or workstations too. The WARNER cluster currently has 21 accounts which were created solely for ASIC purposes, though many are from other groups. Jim didn't think the size would grow much beyond the current count, but I suspect it will.
Adding new user accounts is estimated at 15 minutes apiece (once you know what you are doing in UNIX). This could be reduced to about 5 if a shell script were written (a command file). Writing such a shell script might be a nice way for a new manager to get some practice in UNIX.
A good deal of initial manager time will probably be spent writing shell scripts (command files) to perform small but complicated management tasks. Currently, with one workstation, not many tasks have been scripted. One just doesn't tend to script things until you have to do each task more than times. Then the `bother' level builds high enough that you take the time to script it. I don't know ahead of time what scripts or what small tasks there are, but experience indicates there will be plenty. I still spend a couple of days every few weeks scripting some new small task on the VAX.
Jim foresees each workstation owner handling repair calls on his own node. A manager would want to be informed of failures and repair status, at the least. I suspect each workstation owner may also need assistance in recognizing hardware failures. WARNER workstation owners usually can't tell if a problem is with system software (which they have no control over) or hardware. For those not as familiar as Jim, the manager might well have to be involved to diagnose the problem, even if the user then coordinates the repair.
Some is needed, but what/how is not yet understood, due to the level of UNIX knowledge available. Sounds like Jim's experience is all acquired on the fly. He recommends (for himself or whomever becomes the manager) some of the available courses in UNIX management. Since the ``usage patterns'' aren't envisioned to change on these machines as they do on the VAXes (these will always be running ASIC CAD software), it is thought that an initial system tuning would help greatly, but that ongoing tuning is not so important.
If the other half of the ASIC group were to move to doing CMOS work also, there could be 3 or 4 more SUN workstations added to the bunch. Not in any immediate plans.
More immediate possibility is the addition of a fourth node to act as a file server. This would require time spent in reorganizing the disk structure, as described above.
This is a VAX package which allows communications between DECNET and UNIX systems. MULTINET would allow transferring of files from the SUN systems to WARNER, so they can be fed to the postprocessor software package which Jim has already got licensed for WARNER. Frank Nagy had plans to install MULTINET; I've finished up the installation (Nov 21, 1990).
Udai Pabrai is assisting with a serious mail problem, but no solution has been reached yet. Mail between the UNIX and VAX systems has at least one bug in the addressing area. Mail seems to get through most of the time, but the address is mangled and error messages are encountered. Thus, the integrity of the file is questioned. Udai has the same problems with his node, so some part of this interface or setup is not correctly understood here on site.
Mail is the means of transporting final chip specs to the chip manufacturer, so the integrity of the files transported must be absolute.
UNIX creates files in `stream' format. All the characters are in one long stream. A carriage-return character tells how to output the file to a printer, but is otherwise just another character in the stream. VAX creates files in `record' format. Each line as output to a printer is usually in a separate record. To the VAX, a UNIX file looks like one humongous record.
Accessing the VAX printers from the SUN workstations is possible by just pointing to them. However, the files sent from the workstation reach the VAX printer as one long record, and usually overflow the printer buffer. Jim feels that help is needed with setting up the printers (larger buffers). I'm not sure if the change is required on the SUN or the VAX side. I also wonder if there is any way to convert the file before shipping to the printer (solve the problem from *that* side). There are such conversion programs on WARNER, but Jim says he can't get the file over to WARNER, as it is not a text file.
Coordination and time need to be invested here.