karl@sugar.uu.net (Karl Lehenbauer) (07/22/88)
I've been running Bell Tech Unix System V/386 for the last couple of weeks, and I thought I'd share with the net my impressions, both good and bad. Many of my remarks will apply to all AT&T/Intel/ISC-descended 386 Unix Systems. First of all, this thing is *fast.* Doing big makes on things like news, I have found that, with identical disk hardware, a 16 MHz machine with 64 KB of 0-wait state cache runs nine to ten times faster than an 8 MHz 286. While some of the performance is certainly attributable to the faster clock and such, certainly the architecture of the 386 in native mode with an OS that can take advantage of it is a significant part. Also, with it's 4 GB segment size, most of the Sys V programs that come over the net run on or near the first try, rather than producing the segmentation violations 286 Unix people are used to. BTU comes with two system admin manuals, install notes, and a box of floppies. I understand you can get it on tape. Installation was pretty straightforward, but I was unhappy to see that it displays some stuff like "Unable to write bad track table!" and such, and a thing in the install notes says to ignore it. This is bogus, and I imagine it crept in from the Multibus version, like that they didn't want to become non-binary-identical (other than drivers, Dimitri?). BTU comes with all the stuff that's usually unbundled. You get cc, sccs, f77, yacc, lex...all that stuff. Nroff/troff are not included, because, according to BT, they haven't gone through the validation suite and aren't up to the quality of everything else, but they'll sell it to you, so it's sort of still unbundled. I was really disturbed to see that, after a couple of weeks, process and system accounting had gobbled up 5 MB of disk space. This sort of thing does not give novices warm fuzzy feelings. I knew to look in /usr/adm, as well as other places, to see what was eating my space. This is pretty absurd. I think it should be shipped with process accounting off. Although as a Unix product, it beats the pants off the 286 *Unix* systems that are available, BTU's pretty spare. You don't get kermit. You don't get dosdir or doscp and you don't get a driver that supports most dumb serial boards, like you do with some others. (Which reminds me, why the #W$%&* must cu be so damn picky about letting me get on my lines. I need kermit to see if I'm getting to the modem, and such, because if cu can't place the call, it won't connect you to the port. This is ludicrous.) I'm super, super happy with the product, as a Unix system. I'm looking forward to 3.1 and X support. Maybe I'll even buy a blit card. I'm unhappy, though, that, as shipped, this is still a guru-only or near-guru-only product. I do not think that the average DOS user is going to be able to get and keep it running without spending a lot more time than they want to. There're problems with sysadm (the user-semifriendly system administration utilities), too. At least, I couldn't figure out how to get it to do everything that needed to be done with the uucp config files. I guess we'll have to wait for Next or, gack, AIX, for a reasonably user friendly (and admin-friendly) Unix. To conclude, the AT&T/Intel/Interactive Systems/Bell Tech/Microport 386 Unix is a complete and robust Unix, bringing "full" Unix to the PC-clone world for the first time. It is great for people looking for inexpensive ways to run "real" Unix. It is not, in its current state, going to replace OS/2 or make serious inroads into DOS. Pity :-) (An aside, usage numbers underflate Unix's actual impact in the PC-clone world because many Unix ATs are multiuser, and hardly any DOS and OS/2 systems are.) -- -- backups: always in season; never out of style. -- karl@sugar.uu.net aka uunet!sugar!karl
mike@spca6.UUCP (Michael Nagel Jr.) (07/24/88)
In article <2321@sugar.uu.net> karl@sugar.uu.net (Karl Lehenbauer) writes: >I've been running Bell Tech Unix System V/386 for the last couple of weeks, >and I thought I'd share with the net my impressions, both good and bad. >Many of my remarks will apply to all AT&T/Intel/ISC-descended 386 Unix >Systems. > >First of all, this thing is *fast.* Doing big makes on things like >news, I have found that, with identical disk hardware, a >16 MHz machine with 64 KB of 0-wait state cache runs nine to ten times >faster than an 8 MHz 286. While some of the performance is certainly V/386 is about 2 times faster on a compile than V/AT on the SAME machine. More than 3 times faster after a little kernel tunning. Increasing the disk buffers to 800 and the buffer hash tables to 512 provided a 35% preformance boost. Floppies are another story, SLOWWW!!! Changing the interleave from 4:1 to 2:1 on the floppy increased thru-put by 30%, still unacceptable. Guess they want you to buy their tape drive. >BTU comes with two system admin manuals, install notes, and a box of floppies. >I understand you can get it on tape. Installation was pretty straightforward, >but I was unhappy to see that it displays some stuff like "Unable to write >bad track table!" and such, and a thing in the install notes says to ignore it. >This is bogus, and I imagine it crept in from the Multibus version, like >that they didn't want to become non-binary-identical (other than drivers, >Dimitri?). Even worse, the system defaults to 3:1 interleaving. I have a WD1006 which supports 1:1 interleave. I had to install the system twice, once their way so I could create and mount a copy of the boot disk. Then edit the install script to change the interleave and reinstall. It wouldn't have been so bad if the install had taken the suggested 45 minutes. We're talking hours. Those slow floppies. The install scripts should allow selection of both interleave and inodes per file system. >(Which reminds me, why the >#W$%&* must cu be so damn picky about letting me get on my lines. I need >kermit to see if I'm getting to the modem, and such, because if cu can't >place the call, it won't connect you to the port. This is ludicrous.) In /usr/lib/uucp/Devices find the lines # ---A direct line so 'cu -lculd0' will work # Direct culd0 - 4800 direct add the line Direct tty00 - 2400 direct #change this line to match your system save and type cu -ltty00 As a whole, I'm very happy with BTU V/386. There are some problems with the package but far fewer than V/286. Uugetty was the biggest headache. I finally got it working (sorta) and will post fixxes if others are having problems. If not, guess I did something wrong. The terminfo entry for AT386 needs some work. I removed the definition for rep (just to lazy to fix it since it works fine without it) and replaced the definition for sgr with sgr=\E[%?%p1%p6%|%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;m, This fixxed pcomm, sc and rn, vnews still requires the use of a terminfo entry from an older system. This could be a vnews problem. Vnews uses virtterm.c not curses. Any comments (or gosh forbid, FLAMES)?? Sar -r displays the number of 4k free memory pages NOT 2k pages as documented. Had me a worried when I thought I had less than 1mb free out of 4. I've been running news using 16bit compress for 2 months now and haven't swapped yet. Demand paging, how did I live without it. NO dual drive problems either. V/AT wouldn't even initialize the 2nd drive. Mike Nagel Sixth Circuit Federal Court of Appeals