HFISCHER@USC-ECLB.ARPA (06/15/84)
From: Herm Fischer <HFISCHER@USC-ECLB.ARPA> In preparing for Ada environments at my company, I am attempting to employ distributed Unix systems to offload the ever-increasing demand for computing resources on our central computers. There are lots of PC's and XT's around, but they are mostly used for stand alone work, with the bulk of our engineering acitivities concentrated on hosts. These hosts are loading up to alarming proportions, and a way to offload host jobs would certainly improve response time. Ada tools will further increase our demands for these resources. I have anxiously awaited (since January) for my own copies of PC Unix to begin to attempt to port tools and tasks from the hosts, and to determine how well they perform. (Readers in March remember my astounding observations of speed for Prolog benchmarks.) I have now had enough time on two different PC Unix implementations, IBM's PC/IX, and Santa Cruz's Xenix, to comment on what a PC (XT) is like with Unix. The PC is no longer a toy! It's Unix performance is sufficient, when compared to loaded hosts, to make it's use worthwhile. It's ability to integrate, through Unix communications facilities like UUCP, UUX, and mailers, with networked Unix hosts, is really superb! But, don't expect miracles (yet). If you don't want to read on, I can summarize by saying that both PC/IX, and Xenix will eventually be outstanding products. IBM's has more polish (and fewer bugs) now, and the potential for a really neat multi-windowed forms-driven slick user interface. Xenix's is much more Berkeley-ish, with tools familiar to the most die-hard VI and c-shell enthusiasts. Each system is faster than the other at some things and aggravating at others. Xenix's support crew definately wins out on customer responsiveness (sorry, IBM), by a mile, because "no" and "we will consider it" are not in their vocabulary. Xenix is, however, substantially more expensive than IBM, due basically to a warranty which makes you pay for updates and future releases (free from IBM for two years). Furthermore their license agreement is so restrictive (compared to IBM's) that my next net-note may be from the county jail. Unpacking the Boxes and Installing Unix Both systems come in cartons which seem to weigh as much as a case of wine. Both products come with excellent installation instructions, and lots and lots of floppies. Xenix takes over an elapsed hour to install and PC/IX installs in half the time (I've done each several times). You are in for a tremendous reading assignment if you do not know Unix setup and UUCP setup before you open the box. Manuals Both products basically word-processed the Bell documentation for System III Unix. The differences are that IBM probably could afford to invest more in adding helpful sentences here and there. I hate to say, but you need IBM's documentation in some places and Xenix's documentation in others, for unless you are a Unix expert, each system preserves holes in Bell documentation in different areas. Xenix's typeface is harder to read than IBM's. But IBM let the printing out to a printer whose offset ink smudges under sweaty or greasy fingers. Nobody is perfect... UUCP Communications Bringing up UUCP is usually reserved for a cult of Unix experts who reserve the right to never divulge how the logon files work. IBM's documentation in this area fills in more holes than Xenix's, but it sure takes lots and lots of (and even more lots of) recursive reading and patience. IBM includes autodialer (ACU) code for Hayes, Ventel, and DEC modems, and it works exactly as described (you just have a heck of a time becomming a UUCP logon cult member). I am using a Qubie modem, and the Hayes code drives it well. As of last weekend I still did not succeed with Xenix's UUCP (which only supports Hayes dialers). IBM documents how to write your own dialer code (with Rixon as the example) and the Xenix folks promise to do likewise soon. KERMIT Since I have not yet wrung the last setup error out of Xenix UUCP, I have been using Kermit when using Xenix. Kermit.c, as distributed, with the FIONREAD stuff disabled, works right on the first attempt. However, Kermit.c will not work right under PC/IX. I spent several hours converting the Berkeley stty and gtty calls to the newer IOCTLs, and it still gets hung. With UUCP under PC/IX, I have been too satisfied to finish debugging Kermit yet on it. Is IBM Trying to Announce Unix for the 370??? The connect program (which both systems have), operates similarly to Kermit, in that once speaking to a remote site, you must enter a special escape sequence to get back to the local machine. For PC/IX, the strange escaping sequence, control VM (actually ^Vu^M) leads me to think somebody slipped their tongue on a product whose letters start with VM and end with UNIX. I always loved rumours... Performance Either system, even on as small as a 256K properly configured machine, is better (at simple things) than anybody's medium loaded VAX. PC/IX has a snappier shell response than Xenix. Xenix's C code runs faster than PC/IX's. Basically, PC/IX is two- to four- fold faster than Xenix at shell execution (loading things, getting the editor up, etc.) and editing, for an identical configuration. (This is without making any tasks "sticky" in the swap areas.) But once in execution, the "C" code generated by Xenix is faster. (For example, the UNSW Prolog interpreter runs a standard test at 192 logical inferences per second on Xenix, while only getting 182 per second on PC/IX.) Limitations PC/IX has a 64K size restriction on programs. Xenix doesn't limit code size (medium model). PC/IX limits data structures in "C" to 4K bytes. Xenix doesn't. But both limit data segment size to 64K. The PC/IX restrictions make no sense, especially if one plans to support Ada compilers and programs. The silly 4K restriction is also a problem in porting existing "C" code from PDP/11's and from Xenix systems. Porting an Application I ported a very complex specialized "menu generating editor" program for a DoD terminal product, from the PDP 11 to PC/IX. (It ran into a compiler bug on Xenix.) (I also ran into a PC/IX compiler bug, but it was an easy one to work around.) Since this application only runs on PC/IX, this paragraph only pertains to PC/IX. The "C" routines which write on the CRT, in the printf family, are slower than molasses (140 to 150 characters per second on the console screen). I replaced them with routines to do direct screen memory writes (about ten times faster). These routines, "ibmcur" and "ibmprt" will be submitted to the INFO-IBMPC lending library of public domain software in a separate message. (These routines are most interesting, because they show the casual hacker how to embed assembler code in his "C" programs, and how to access memory outside of the 64K allocated data segment.) (Perhaps the slow speed of screen writing is due the the enormous flexibility the PC/IX console handler has. An Interactive employee called the handler a "brain-damaged" ANSI emulation. I disagree; you can set colors, erase in fields, selectively scroll, and even run most vt100 code. But to do this within the vertical retrace period of the color display slows writing speed down!) Editors PC/IX is Interactive-ish in flavor, with a distant cousin of the Rand Editor; Xenix supports a version of the VI editor. PX/IX has a quarterplane style editor, with full keyboard integration, online help, pop-up menu's, pop-up windows, fill-in forms (structured files), multiple windows, and more to come. (They tell me at Interactive that a product soon to be available on the VAX, "ten-plus", may be distributed by IBM for the PC. I have seen this product and eagerly await it. I saw a developer editing his "C" code, popping up a menu and selecting compile, and after a pause, seeing the error messages in pop-up boxes pointing to the respective offending syntactical construct. It sure makes Unix more user friendly, even if the editor now becomes a pseudo shell. I'd love to have this for Ada!) The Xenix VI is honest VI. A mode-sensitive non-quarterplane editor, but well loved by many users. (I am partial to EMACS. Sorry, Xenix.) The Xenix VI editor does not work with my (Logitech) mouse; it presently only uses standard VI commands ("hjkl" for cursor movement). The PC/IX editor supports the mouse, though it crawls slower on screen then under my hand. If you want windows and menus under Xenix, it has v-shell; however, this program crashed the system several times for me. V-shell is basically the same as R.F. Starr's "UTIL" freeware program under PCDOS. Impressing Your Friends with Dial-Up Ports Both Xenix and PC/IX allow you to enable your modems on the asynchronous ports and have up to two dial-up remote users. I leave my system on at night in the office, and call it from a terminal at home. Unless your remote users try to do "makes" or otherwise pig-out the feeble 8088 CPU, response time is not much worse than with a loaded VAX. PC/IX even distributes accounting software, with instructions on how to charge for usage like a big host. A **MAJOR** PC/IX annoyance is that the editor, with all of its wonderous user friendliness, is not runnable remotely. When I go home and call up my PC with PC/IX, I must grovel and use the yucky ED editor. All (with no exception yet found) other PC/IX programs seem to work properly at remote terminals. I know that this editor is written for VAXes and 11's to work with regular remote CRT's. (The PC/IX version obviously does direct console screen-writes, and will not work remotely; even if IBM were to have to charge extra to have the editor work remotely, it would be worth it.) VI works with all terminals, local and remote, on Xenix. I do not recommend planning to have multiple online users doing any CPU-intensive work; both systems are really only as fast as the 8088. Minimal Systems Both systems run decently on a "properly configured" 256K machine. But they degrade differently. PC/IX seems to run at the same speed (as a large memory configuration), when executing a program or the editor, and just slow down when loading programs, starting print spool activity, and the like. If you let cron do its "sync" every minute (as distributed) the 256K program will stop while the swapping occurs (2 seconds or so). That is disconcerting while editing, but easily remedied. Xenix, unless you disable the remote ports, will crawl in 256K. (15 minutes to do a 1 1/2 minute compile, for example.) With ports disabled, it's performance is nearly the same as with more memory; and, when swapping activity occurs, Xenix is more graceful, becomming sluggish at the VI cursor but not stopping you entirely as PC/IX does. Jailtime The license agreement for Xenix restricts Unix use to a single machine. An expensive product, and you cannot even use it at home in the evening and upstairs at work when your secretary is fancy-fonting under PC-DOS. You cannot even loan it to a friend for him to try on his PC on the weekend. IBM wording is far more lenient; you can only use it on one machine at a given time, and they do not even ask you to specify the serial number. Conclusion Unix for the PC is here. Two honest Bell System III ports have been reviewed, and both perform surprisingly well. Idiosyncrasies are different for each system. The smaller company is more responsive; the larger has more user friendly software. For every strength you will find a peeve. Time will straighten things out. Competition is wonderful (especially for software products). -------