brownrigg@kuhub.cc.ukans.edu (01/24/91)
(this isn't exactly the right news group, but its as close as they come...) 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? Thanks Rick BRownrigg Kansas Geological Survey
boylan@spectacle.sw.stratus.com (Richard Boylan) (01/25/91)
In article <28117.279dbffe@kuhub.cc.ukans.edu>, brownrigg@kuhub.cc.ukans.edu writes: |>(this isn't exactly the right news group, but its as close as they come...) |> |>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? |> |>Thanks |> |>Rick BRownrigg |>Kansas Geological Survey I didn't work on DG/UX too much, but I did port some of the system software to it. Some of the reasons I can think of why the MV architecture would be unfriendly to Unix: * The MV architecture, like all Data General proprietary architectures, has a different format for byte pointers and word pointers. Changing from one to the other involves a shift right or left by one bit. Software that is less that impeccable in its pointer typing will invariably not run without some work. * MV stacks grow upward, while Unix has a bias towards downward- growing stacks. * With only four registers, programs that were carefully tuned to run well with 8 or 16 registers ran terribly. * DG's own C compiler was pretty much the only C compiler available. The merits of this compiler have already been discussed here. But suffice to say that while it was one of DG's best proprietary compilers, it was not comparable to state-of-the-art C compilers. * Other tools like assemblers and linkers were ported AOS/VS tools, and any similarity between them and the generic Unix tools was minimal. To its credit, DG/UX did have some points in its favor. For example, I was told that it was one of the first decent implementations of demand-paging for UNX. But as I said, I did not use it much. Perhaps other DG alumni can say more. Richard Boylan Stratus Computer boylan@spectacle.sw.stratus.com
john@amc-gw.amc.com (John Sambrook) (01/25/91)
In article <28117.279dbffe@kuhub.cc.ukans.edu> brownrigg@kuhub.cc.ukans.edu writes: >(this isn't exactly the right news group, but its as close as they come...) > >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? > When I was working at the University of Washington we ran both AOS/VS and DG/UX (and, at one point, MV/UX, ugh.) on an MV/10000. Nobody noticed any appreciable speed differences. The only real differences when running DG/UX were: 1. For the first year, every time you called the SSC in Atlanta, the conversation went something like this: US: "We're having a problem with our operating system ...." SSC: "Is EXEC running?" US: "This is Unix. We don't need no stinkin' EXEC." SSC: "You're nuts. Everyone's got an EXEC." US: "Read my lips. Dee-Gee-You-Ecks, not Emm-Vee-You-Ecks!" SSC: "Oh ..., let me transfer you .... click-click-hummmmm" 2. At least up until I left, the IAC code under DG/UX was never very reliable. 3. The product was generally at least a year and a half behind the state of the BSD and/or Sun worlds, at least in terms of networking support. E.g., no support for nameservers, etc. 4. Everyone was glad to be using UNIX instead of AOS/VS. 5. The C compiler was absolutely wonderful compared to the garden variety UNIX compilers of the time. I only ever discovered one bug, which was fixed in the next revision. I'd like to suppose that all of these issues have been resolved since I left the University about a year ago. But I doubt it. I also doubt that DG can afford to spend anything on development of DG/UX for the MV line. Why would anyone buy an MV these days? Seriously, DG had a lot of good people, but the timing was about five years too late. Only my opinions, mind you! -- John Sambrook DNS: john@amc.com Applied Microsystems Corporation UUCP: amc-gw!john Redmond, Washington 98073 Dial: (206) 882-2000 ext. 630
jcw@ksr.com (Jay Wilkinson) (01/26/91)
brownrigg@kuhub.cc.ukans.edu writes: >(this isn't exactly the right news group, but its as close as they come...) >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? FYI: The biggest pain with UNIX and MV arch that I was aware of was that word pointers were not byte addresses. This caused endless problems with many applications that assumed that all pointers were byte pointers. DG eventually added a switch to allow C to force all pointers to byte addresses as they were stored to memory. ugh! I also remember NULL pointers causing problems, any read/write to 0 caused a protection fault which would normally cause program termination. -- Jay "ex-MV-guru" Wilkinson jcw@ksr.com -- Jay C. Wilkinson jcw@ksr.com Kendall Square Research Corp. uunet!ksr!jcw 170 Tracer Lane Telephone: (617) 895-9403 Waltham, MA 02154-1379 FAX: (617) 890-0996
OSmith@acorn.co.uk (Owen Smith) (01/28/91)
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).