[comp.unix.microport] semi-review of Bell Tech Unix for the 386

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