semi-review of Bell Tech Unix for the 386

[Michael Nagel Jr.]

In article <2321 at sugar.uu.net> karl at 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