Dear Ladies and Gentlemen,
   
   I have been participating in several interesting discussions on port-
vax, but I have never actually introduced myself to the club, and some of
my comments may make some of you wonder who I actually am. So let me
introduce myself to you. Sorry if this is off-topic.
   I am Michael Sokolov, the System Manager of the so-called Harhan Project
at Case Western Reserve University (CWRU). This is a volunteer project
aimed at building a new UNIX system on our campus. Since this is a
volunteer project, it is being run on donated hardware, and it is my
superior knowledge of old computer hardware that holds me securely in the
position of the System Manager. The goal of the project is to build a real
system in full production, supporting at least hundreds of users total and
at least 80 users simultaneously. It is going to be competing with Pentiums
and SPARCs. This is quite different from playing with a single box at home,
and requires a lot of guts and a lot of boxes to divide the load. I will
need a whole bunch of machines, 5 at least. Although we are limited to old
hardware, it comes in many architectures, and I have the authority to
choose one for Harhan. At very early stages of the project, I was
considering 386es and 486es, but then I had quickly changed my mind to
VAXen.
   The reasons for choosing VAXen over PCs are both practical and
ideological. As the System Manager, I can't allow myself to be guided only
by ideological reasons, and whenever I want to follow my ideology I first
have to find a practical justification for it. The chief practical reason
for choosing VAXen is that people give them up readily, even very good
ones. No one would ever give up a PC as good as some of the VAXen that I
get. The only PCs that people give up are complete junk. 386DX-20s AT MOST,
and even those are so crappy and non-standard that UNIX would never run on
them (examples: HP Vectra, AT&T, IBM PS/2, etc.). No one would ever give up
more than 8 MB of PC memory, while most VAXen that I get have at least 16.
When I was planning to use a 386-or-486, my greatest hope was a 500 MB IDE
disk, and I had realized very quickly that no one would give one up. The
largest IDE disk I could get was 80 MB. For VAXen, on the other hand, I
have a whole bunch of ESDI and SMD disks with SEVERAL GB total FOR FREE.
And remember that I need a whole bunch of machines, 5 at least. Finding so
many suitable PCs is simply not realistic. With VAXen I have many more
boxes, and I'm already close to my start-out goal of 5 suitable ones.
   The ideological reason is that the so-called "modern PCs" are shit from
the architectural viewpoint. I like real computers with a highly structured
architecture, where every logical device is an actual board, where all mass
storage devices have purely physical interfaces (like ST-506/412, ESDI, and
SMD), and where every type of mass storage devices has an actual controller
board. With VAXen this is ideally satisfied, especially with Q-bus ones. On
the other hand, PCs are constantly going downhill with controllers on the
motherboard, IDE, plug-and-play, PCI, and other shit. The highest good PCs
are 386es with standard motherboards, separate ISA cards for everything,
and ST-506/412 or ESDI Winchester interfaces. But such 386es are awfully
hard to build. One has to build them piece by piece, obtaining each piece
with a lot of trouble, if one wants to build a really good ideologically
pure 386. That's what I'm doing for my home PC. I started building it in
mid-summer 1997, and I'm still not quite done. (It is going to run DOS,
BTW, no UNIX whatsoever. With UNIX it would be even more difficult.) Doing
this for five machines will certainly take long enough for my sponsors to
get disenchanted with me.
   And so I had decided on VAXen and started accumulating them. After a
while I had accumulated the following: a practically unlimited number of
VS2000 system units, 5 VS3100 M38 system units, 1 KA650 CPU, a MicroVAX II
630QB (BA123) box, 1 676 MB formatted ESDI Winchester (originally there
were 4 but I had to take 2 for another purpose and 1 doesn't spin), 2
RD54s, 1 RZ23, and a number of 8" SMD Winchesters which I haven't
investigated yet. Having accumulated all this stuff, I started thinking
about how to layout the UNIX "cluster". The topology that most UNIX
"clusters" use is star: a single disk/mail server (the central server)
keeps the home directories and mailboxes on huge disks and accepts all
incoming mail, and a number of login machines ("satellites") NFS-mount from
the disk/mail server, using their small local disks for the OS and other
static software/data only, and allows users to log in and run processes. I
see no reason to deviate from this classical scheme, so all I need to do is
to choose what to use for the central server and what to use for the
"satellites". (When using terms like "cluster" and "satellite" I don't mean
the original VMS meaning, just similar concepts.)
   The VAXen that I have fall into two categories: classical VAXen and
BabyVAXen. I have to use my own terminology since there is no standard one
for this. By classical VAXen I mean VAXen that consist of UNIBUS-type buses
and controllers that are typical for such buses. Q-bus MicroVAXen are
classical VAXen, since Q-bus is a UNIBUS-type bus. They are rather simple
classical VAXen, though, since they have only one such bus and don't have
extensions to the architecture like MASSBUS. By BabyVAXen I mean busless
VAXen that consist of a single system board. The only UNIXable BabyVAX
system boards are KA410, KA42/41, and KA43. Fortunately, all of my
BabyVAXen are UNIXable.
   From purely ideological considerations I like classical VAXen better,
for exactly the same reasons why I like classical 386es. But just like
386es, these things consist of parts and pieces, and therefore I have to
build them, since the chances that what I get will match what I need are
just too grim. I can't do that with 5 or more machines, so I can't use
classical VAXen for all of my "satellites". The most likely scenario is
that I'll build one Q-bus MicroVAX and make it my central server, and use
BabyVAXen for all "satellites". Of course, I would need to equip all
machines properly. For instance, I plan to increase the memory on all
machines to the maximum. Each "satellite" will need a small disk to hold
the OS and other software, and the central server will need huge disks.
   I have been thinking a lot about the situation with the central server.
The maximum performance I can squeeze out of a Q-bus MicroVAX is 3.8 VUPs
if I put a KA655 CPU in it. This is the same as what I can get out of my
current BabyVAXen (the fastest I have is VS3100 M38). And I may at some
point come across a VS3100 M76, although I'm not actively looking for one.
So I was wondering whether I should stop playing with Q-bus MicroVAXen and
use a VS3100 M38 as my central server. Of course, a Q-bus system with lots
of 8" and 5.25" full-height Winchesters in three wheeled cabinets (one
BA123 and two Sun 8" drive cabinets) is MUCH more fun than a skinny 3100,
but again, the System Manager is not supposed to base his decisions on fun.
Plus using a Q-bus MicroVAX for the central server may very well lead to
some hard dollar cost (i.e., having to beg my sponsors). I currently don't
have a KA655, only a KA650, and unless I'm extremely lucky to come across
one, I'll have to buy one on the used DEC market (having the central server
slower than the "satellites" is just ridiculous). Also I currently don't
have a controller for my wonderful 8" SMD Winchesters. On the other hand,
if I were to go the BabyVAX way, I would need either new SCSI disks or, if
they still exist, a SCSI-to-SMD controller and a SCSI-to-ESDI controller.
Again hard dollar cost is unavoidable. My only valid justification for
using a MicroVAX 3/3+ instead of a BabyVAX is that on the former I can put
64 MB of RAM and on the latter only 32.
   Recently I have also been able to do the impossible: convince our local
DEC field service office to help me out. I have called them, introduced
myself as being from CWRU, told them that we are in a difficulty and that
they should really help us out since CWRU has been an extremely profitable
customer for them. When I was discussing this with others at CWRU before,
they had told me to keep my expectations low, so I wasn't hoping for much,
but to my great joy they agreed, and I was told that an engineer was going
to call me back. He did, and now he is helping me by going through all old
DEC customers in our local area and gathering hardware for me. I haven't
seen it yet, but from our phone conversations it looks like there is
something impressive in there. So what I finally decide to do depends
greatly on what I manage to get from DEC. Also Richard Parobek (the guy who
is helping me) has promised to find some docs for me.
   Now the tough part. The operating system. I probably shouldn't say this
on a NetBSD mailing list, but I really like the genuine Berkeley UNIX(R)
better than various GNU-infested "free" Unices. PLEASE UNDERSTAND that not
liking NetBSD CODE does NOT mean not liking NetBSD PEOPLE. I have the
highest respect for Ragge all other people who have made NetBSD run on
BabyVAXen, which Berkeley UNIX(R) has never supported. It's just that I
like the original V6/V7 utilities better than their GNU "equivalents". But
regardless of how I justify this, I have a paramount task to do:
resurrecting Berkeley UNIX(R). The reason for this is that the flavor of
Berkeley UNIX(R) that I want to use doesn't currently exist, and I'll have
to construct it from those that do. First, there is pre-Reno and post-Reno
stuff. I strongly oppose any smell of System V or POSIX, so of course I
want the pre-Reno shell, utilities, and terminal I/O. On the other hand, I
like some things that have been first introduced in Reno: better thought-
out directory layout, NFS and Kerberos which are essential for UNIX
"clusters", and probably some improvements in the kernel. So this is one
task already: take the classical code out of the original 4.3BSD and stick
into something post-Reno. This means that my main code base must be
something post-Reno. I would also like it to be a stable release, rather
than an intermediate one like 4.3BSD-Reno or Net/2. These requirements
spell out 4.4BSD. But then there is another problem: the new VM in 4.4BSD
has broken the VAX support, so I'll have to either fix it or put the old VM
back. And finally, Berkeley UNIX(R) support for VAX ends with KA650.
BabyVAXen are not supported. I would have two choices for BabyVAX support:
port it from NetBSD, or from the pmax port of 4.4BSD itself. (DS3100 was
very similar to BabyVAXen in all respects except the CPU.) The latter may
actually be easier, since the code in written in C, so the CPU shouldn't
really matter as long as the peripherals themselves are the same, but the
kernel interfaces in NetBSD are probably quite different from those in
Berkeley UNIX(R).
   In any case I will have enough work to do to keep me busy. Meanwhile
I'll run NetBSD/vax on one of my VS3100s M38s (by itself, without
"clustering").
   
   Sincerely,
   Michael Sokolov
   Phone: 440-449-0299
   ARPA Internet SMTP mail: mxs46@po.cwru.edu