bjorn@alberta.UUCP (Bjorn R. Bjornsson) (08/08/86)
I would like to here about peoples experiences with Amdahl UTS and/or IX/370 under VM. Indications of implementation quality, efficiency, horror stories, price (including maintainance if available), etc., is what I'm looking for. Doubly interesting would be any info relating the above to an IBM 4341. Thanks, Bjorn R. Bjornsson Department of Computing Science University of Alberta alberta!bjorn
narayan@twg-ap.UUCP (Narayan Mohanram) (08/09/86)
There is no comparison between the two. UTS is fast, and real UN*X.
Also with the Amdahls' session functionality, you can't beat it. It
is by far the best System 5 I have seen to date.
IX370 on the other hand runs on top of RSS which is the real OS
which runs on top of VM. You have problems in flakiness of the
system. Also as process are all controlled by RSS, signaling
has a few quirks that are really frustrating.
If you need to work in the kernel, IX370 leaves a lot to be desired.
--
Narayan Mohanram
Phone: 415-962 7170
ARPANET twg-ap!narayan@lll-tis-b.ARPA Down for the moment
Usenet ihnp4!amdahl!wg3b20!narayan
Mail The Wollongong Group
1129 San Antonio Road
Palo Alto, CA 94303. USA
=========================================================
|| If you can't lick it, try some whipped cream ||
=========================================================davidsen@steinmetz.UUCP (Davidsen) (08/15/86)
In article <39@alberta.UUCP> bjorn@alberta.UUCP (Bjorn R. Bjornsson) writes: >I would like to here about peoples experiences with >Amdahl UTS and/or IX/370 under VM. Indications of >implementation quality, efficiency, horror stories, >price (including maintainance if available), etc., >is what I'm looking for. We have been running IX/370 for some time. The following is my personal experience with it... the kermel is SysV as you would hope. The utilities *seem* to be the PC/IX utilities, SysIII with additional non-standard commands and options hung on. For example, the 'ls' command has none of the SysV options, but there is an 'li' command which is, in many ways, better. Just don't try to run a SysV shell script. The vi editor is missing, but there is the 'e' editor (INed) which is a *fine* editor, but requires the services of a guru to run with any terminal other than vt100 or PC running PC/IX. On the good side, EMACS (UniPress) dropped in and runs perfectly. Programs larger than 100k or so tend to create lots of page faults, resulting in poor performance in realtime. The mail system is a cobbled mess of SysIII and INteractive Systems mail. When first delivered it required the text editor to read mail! My favority 'mailx' is just not there. On the good side: really truely FAST!! The C compiler must work pretty well, most programs run about 10x a VAX 11/780. This is really nice if you are working with nroff and a large document. The performance is, again, about 10x a VAX. uucp performance has been enlightening. For a while 1200 baud was the fastest speed in terms of effective thruput. This has been more or less fixed, but it is still about 2:1 slower than going VAX to VAX. Overall this is a very fast system, but not particularly compatible with most existing releases. Since a lot of the system stuff has pathnames starting with 'uts', I wonder about the source of this version. Perhaps someone running a real UTS system can tell us. There is also a SysV from AT&T now, but I don't know any details. -- -bill davidsen ihnp4!seismo!rochester!steinmetz!--\ \ unirot ------------->---> crdos1!davidsen chinet ------/ sixhub ---------------------/ (davidsen@ge-crd.ARPA) "Stupidity, like virtue, is its own reward"
bzs@bu-cs.bu.EDU (Barry Shein) (08/20/86)
I tried IX/370, first on our 3081 and later on our 3090/200. I will say that the IBM developers spoke with me about my reactions and were very receptive, so some of the criticisms below (none of which are horribly fatal) were noted and may very well be getting fixed as we speak. Good points: It is SYSVR1, pretty much complete. On my system (see above) it was *FAST*. I'm talking about doing C compiles and having the prompt come back so fast I thought it must have somehow missed the command, really! I had to check! I measured over 31,000 dhrystones which remains in the recent listing the fastest result. It may be faster than that, there were over 150 users on the system when I got that result. They handled the base-register problem a little more elegantly than the C/370 system we had previously been using. This means that a base register on an IBM can only handle 4K offset, so larger things w/in a C program need to allocate more base registers and its hard to predict on the fly (I guess, never looked closely.) IX/370 would just automatically re-start with more base registers (or the user can request more in, eg, a make file.) As noted above about speed, this is adequate (at least you don't have to understand the problem, I do, but our students never do.) UUCP existed (hey, that's progress for a 370.) I had very little trouble moving random things that make our user environment a little nicer. Of course, this is partly due to the fact that we had already moved a lot of this to our 3B5 so it had been cleaned up once, and that the 370 architecture is by and large compatible in philosophy with Suns, Vaxes and 3Bx's (32 bit words etc etc.) Bad points due to the implementation: It was SYSVR1 (which is why it didn't have mailx as another poster mentioned.) I am sure it will move ahead in releases, so this should be a minor complaint. It did not and could not integrate with WiscNet (IBM's TCP/IP) which in our environment is a major negative, but perhaps not yours. This, however, was a point of agreement between us and the developers so I expect it to be fixed. There was no general way to access VM objects, particularly spools so you could do something like punch to another user's reader spool which would be a way to effect mail in the IBM way to a CMS user. Again, noted, agreed. Note that you can configure in printers, it's just the general case that was weak. They were loathe to provide sources even for a price. We would have been more than willing to provide access to the needed DIAGNOSE's to do some of the above and design the syscall interface to be UNIXish. I think that philosophy is a mistake on the part of IBM, we really could stand on each other's shoulders on things like this. The Series/1 is an ancient way to provide a terminal front-end, this should be re-thought and the current implementation scrapped (noted, agreed.) There should be general 327x support and DIAL support (or equivalent), noted, agreed. I think that IN stuff they threw in was unnecessary, I'd prefer if they concentrated on other areas. It's supposed to be 'user-friendly' but none of us could figure out how to use it. They should be more aware that in this day and age people know UNIX, or learn it and have to use it on other systems. These user interface oddities are rarely worth the effort when something that worked fine existed already. If it ain't broke, don't fix it! They should look into more efficient ways to create processes taking more advantage of the stand-alone'ness of the VM environment (noted, no comment other than 'interesting', there are more details here.) The manuals have been re-organized to be more 'user-friendly' (which I think just means using larger fonts...ok, ok, just kidding.) I explained that in doing so they have obviated the possibility of on-line manuals (and, most importantly, on-line tools to data-base the manuals.) There were no on-line manuals offered. Noted, soft moans of pain, they thought we would love this new format and had worked very hard on it, I didn't, sorry, go back to the old format PLEASE, and give us on-line manuals PLEASE! Bad points not due to the implementation (ie. inherent in SYS/V): No disk quotas may be fine for little machines, but our 3090 has around 15,000 users and around 20GB of disk. With that kind of community you can't just send out friendly little "please clean up your disk area" notes, you need some administrative tools that work. (noted, agreed in principle, but nothing promised.) Predictably, we would like some 4.xbsd kernel support, such as ptys, sockets (I guess streams would be ok), job control etc. (noted, but SYSVness re-iterated, oh well, I asked for sources again at that point.) ----- Summary: I have no experience with UTS so I cannot compare. By and large it was a fine job but I'd like to see some firmer commitment to solving most of the above problems. The disk quota problem FOR US is severe enough to make us hesitate to commit to it, but again, that's largely because we run a student system with such a huge community, it may not matter much to you. If you like SYSV you will like probably this product. -Barry Shein, Boston University
tewok@umd-brillig.arpa (Uncle Wayne) (08/20/86)
In article <39@alberta.UUCP> bjorn@alberta.UUCP (Bjorn R. Bjornsson) writes: >I would like to here about peoples experiences with >Amdahl UTS and/or IX/370 under VM. Indications of >implementation quality, efficiency, horror stories, >price (including maintainance if available), etc., >is what I'm looking for. About 2 years ago, I played with an account on an Amdahl UTS system. I only had a day or two on it since the systems staff didn't know if they wanted to run it. There are two things I remember about it. 1) I logged on to the same account at the same time from different terminals. When I logged off of one of the accounts, UTS died also. 2) They apparently had csh. One person on the systems staff decided that sh would be for the everyday users and that csh would be reserved for the systems accounts. His justification? None that I know of. He probably just wanted to have something he could use that the average scum-user couldn't. Yes, that is the way his attitude was. I'm sorry I can't give any more specifics about it than that. As I said, it was 2 years ago and I shouldn't have had access to the account I had. (UTS was there for testing and I was just an average scum-user. Wayne Morrison ARPA: tewok@brillig Parallel Computation Lab UUCP: seismo!umcp-cs!tewok University of Maryland (301)454-7690
tweten@AMES-PRANDTL.arpa (Dave Tweten) (08/20/86)
From: bjorn@alberta.UUCP (Bjorn R. Bjornsson) I would like to here about peoples experiences with Amdahl UTS and/or IX/370 under VM. Indications of implementation quality, efficiency, horror stories, price (including maintainance if available), etc., is what I'm looking for. We have been running Amdahl UTS/V version 1.0, under VM version 3, on two Amdahl 5840s for about a year. We just got the 1.1 and 1.1.1 UTS/V updates, but will probably hold out for UTS/580 (which is on order). We are also about to upgrade to VM/HPO version 4. Both flavors of UTS are basically System V.2. The good news is that UTS supports a lot of users and a lot of 3380 look-alike disk. Up to 100 9600 baud RS-232 connections at a time can be made through our Micom switch and Amdahl 4705E communications controller. We support 50 simultaneous production users, or so, for most of the day, on one virtual machine, on one of the 5840s. We are developing one of the 5840s as a GIANT disk server (about 40 Gig, to start) for our ethernet and HyperChannel based TCP/IP networks, which include a Cray-2. There is also some bad news: 1. The TCP/IP support on the ethernet had to be added-in (Wollongong), and we had to roll our own HyperChannel support in UTS (not strictly necessary anymore) and in VM, to permit virtual machines to share adaptors (still required). 2. Version 1.0 of UTS had many bugs (so what do you expect from version 1.0?). We did a LOT of bug fixing and Amdahl fix integrating. Supposedly, version 1.1.1 is much better, but we'll probably never know. 3. The C compiler occasionally produces some strange code. For a while, that prevented Unipress EMACS from working in all its glory. It STILL doesn't work in all its glory, though the latest reason is unknown. 4. Because UTS/V depends upon VM, it is unprepared to deal with all the perversity of I/O devices in the real world. That can be the source of some considerable headaches if you want to roll your own drivers for bizzarre devices (as we did for the HyperChannel). Again, the advertizements say UTS/580 will make it all better. We'll see. 5. High speed disk I/O through UTS/V is a problem. It seems to do only sector I/O. The ability to support track I/O would push maximum sustained I/O rates above their present 2 megabit per second upper limit. So would cached controllers (for read), or a ramdisk (for the truely desparate). On balance, I think we are reasonably satisfied, all but the if-you-have- EMACS-you-don't-need-a-shell crowd.
jon@amdahl.UUCP (Jonathan Leech) (08/24/86)
In article <897@kbsvax.steinmetz.UUCP>, davidsen@steinmetz.UUCP (Davidsen) writes: > We have been running IX/370 for some time. The following is my personal >... > On the good side: really truely FAST!! The C compiler must work pretty > well, most programs run about 10x a VAX 11/780. This is really nice if > you are working with nroff and a large document. The performance is, > again, about 10x a VAX. On what machine? 10x 780 would be most impressive on a 4341 but dismal on a 3090. > Overall this is a very fast system, but not particularly compatible > with most existing releases. Since a lot of the system stuff has > pathnames starting with 'uts', I wonder about the source of this > version. Perhaps someone running a real UTS system can tell us. There > is also a SysV from AT&T now, but I don't know any details. UTS is Amdahl's System V port for 370 architectures. It runs both native and as a guest under VM. Since I have an obvious bias I won't say any more (but will be happy to answer questions via private mail). -- Jon Leech (...seismo!amdahl!jon) UTS Products / Amdahl Corporation __@/ This article does not represent the views of Amdahl Corporation.
faustus@ucbcad.BERKELEY.EDU (Wayne A. Christopher) (08/25/86)
In article <3565@amdahl.UUCP>, jon@amdahl.UUCP (Jonathan Leech) writes: > UTS is Amdahl's System V port for 370 architectures... > > This article does not represent the views of Amdahl Corporation. You mean that you've been doing this port without Amdahl's knowledge, and attatching their name to it? For shame... Wayne
jon@amdahl.UUCP (Jonathan Leech) (08/27/86)
In article <982@ucbcad.BERKELEY.EDU>, faustus@ucbcad.BERKELEY.EDU (Wayne A. Christopher) writes: > In article <3565@amdahl.UUCP>, jon@amdahl.UUCP (Jonathan Leech) writes: > > UTS is Amdahl's System V port for 370 architectures... > > > > This article does not represent the views of Amdahl Corporation. > > You mean that you've been doing this port without Amdahl's knowledge, and > attatching their name to it? For shame... > > Wayne No, I mean that people should not assume I am speaking officially for Amdahl, twit. Keep the jokes in other newsgroups. Jon Leech (...seismo!amdahl!jon) UTS Products / Amdahl Corporation __@/