(Have only included the sections to which I am replying - hope that
	is OK)

On Sun, 11 Jan 1998, Michael Sokolov wrote:

> [ Background for volunteer project to build a new UNIX system at CWRU ]
>
>                                         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".

	It might help to work out the services you are intending to
	provide in more detail, to better match machines to tasks.
	eg: it might make sense to have a VS3100/38M each for email
	and www (assuming you are interested in having a web server :),
	to keep load off the central servers.

>    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.

	Assuming you're not using the main server for anything but file
	serving, IO and memory (for a cache) is going to be more of an
	issue than CPU. That extra 32MB used in the buffer cache could
	give a real win...

	Then again, depending on how far you need to scale, having
	multiple fileservers is always an option :)
	
	It all resolves around what hardware you get from your local DEC
	friend!

>    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. 

	The only reason NetBSD uses any gnu code (& its all kept to a
	different area of the source tree) is to fill in the gaps in Net/2
	& 4.4/Lite. The kernel is totally free of GNU code.

>     ... 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.
>
> [ 4.4BSD not containing any VAX support ]
>
	Can you get the UNIX source licence that allows you to use the AT&T
	code in 4.4BSD?)? Without it you cant use 4.4BSD, only 4.4/Lite,
	which has had all the AT&T code removed, and is nowhere near a
	complete (or even runnable/compilable) system.

	If you cant get the licence then you probably have to accept gnu
	tools to fill in the gaps - and NetBSD is probably the best
	source tree to start from, and then shift back whichever userland 
	utilities amd libraries to give the interface required.

	If you do have a licence, then its probably worth looking at
	taking NetBSD and dropping in the old BSD tools to supplant their
	gnu replacements.

	Starting with the NetBSD tree gives you support on all your
	machines (plus the promise of more to come), plus you can (if you
	choose), track changes/fixes to the source.

	Whatever you choose - good luck!

		David/absolute

       ( Now you know "What would happen"... Disappointing isn't it? )