Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!ukc!acorn!OSmith
From: OSmith@acorn.co.uk (Owen Smith)
Newsgroups: comp.os.aos
Subject: Re: DG/UX on an MV/20000???
Message-ID: <4800@acorn.co.uk>
Date: 27 Jan 91 17:57:00 GMT
References: <28117.279dbffe@kuhub.cc.ukans.edu>
Sender: osmith@acorn.co.uk
Distribution: comp
Organization: Acorn Computers Ltd, Cambridge, England
Lines: 58

In article <28117.279dbffe@kuhub.cc.ukans.edu> brownrigg@kuhub.cc.ukans.edu
writes:

>Can anybody share their experiences with DG/UX running under the MV
>architecture?  It was indicated by the local people that Unix and the MVs
>were a very poor match, and that performance was atrociously slow.  I hope
>this isn't true!  What would be peculair about the MV arch. that would
>promote this?

At DG's Development Lab Europe we had some MV's running VS, one MV running
DG/UX and several Aviions. When DG/UX 4.10 first came out for the Aviion
we used the MV running DG/UX 4.01 as the YP master, because the Aviions used
to panic about twice a day but the MV stayed up for months. However, the MV
(an MV 7800 XP with 14MB memory) was very slow in comparison to the Aviions.
About the time I left, DG/UX 4.30 was out on the Aviions and we moved the
YP master to an Aviion and switched the MV off - it was just too slow to
be worth using compared to the Aviions. Also, DG/UX 4.01 was the last version
for the MV. All future versions of DG/UX (as far as I am aware) will be for the
Aviion only so it doesn't look like a particularly wise proposition to run
DG/UX on an MV to me.

Anyway, why on earth would you want to run Unix on the MV when you could
be running AOS/VS II on it? At least VS isn't full of shoddy code and 
security loopholes. VS also has commands with names longer than two letters.

More seriously, if you have an MV lying aorund that you want to use in your
Unix network, try running AOS/VS II and ONC/NFS server software on it and
just use it as an NFS disk farm. I ran this on an MV 15000/20 with 32 MB of
RAM and 7 512 MB R.A.M.S. (Shadows) disks. This worked quite well. Although
other people in the lab disagreed (on principal) I think the MV was a faster
disk server than the Aviion 5000 series systems we had. The 5000's were
serving 4 diskless workstations each, and with only 16 MB of memory they
were continuosly running out of page and swap. (Stupid idea, putting page
and swap in a seperate fixed sized disk partition - the heads move back
and forth like crazy, and page and swap can be full but the rest of the
disk is half empty.) I put the swap file for my diskless Aviion onto
the MV. This worked very well, especially since the MV had more free disk
space so I could make my swap file much bigger. Also when I created the swap
file on the MV I gave it an element size of 32 and created it on a relatively
empty disk, so I got a completely contiguous fast access 36 MB file. (Remember
to write a value other than zero to the bytes in the file if you do this or
the blocks won't get allocated.) The only problem with this is that you have
to patch :UTIL:ONC:MOUNTD.PR as it is very stringent about the types of files
you can export as mount points. I believe that this change may now have been
incorporated into the software. It wasn't in rev 1.00, so check the release
notice if you want this feature. Also tpying "ls -l" in a mounted VS directory
is (or was) very slow. This is not indicative of the general speed and I
believe this may get fixed at some time in the future. ONC/NFS for the MV
seems to be very reliable too - when I thought I had found a couple of bugs
in it, they in fact turned out to be bugs in the DG/UX 4.30 client NFS
software, although the Unix guys seemed to be rather slow to admit this
("it works with an Aviion server, so it must be OK" was their attitude).

Well I've probably waffled too much about stuff you're not interested in
already, so I'll stop now.

Owen (ex AOS/VS II system manager and C programmer).