ISC update

[Larry Snyder]

Well - nstar is now back up and running under 386/ix.  It really was easier 
than I thought - expire everything in both the news and akcs message bases 
(this took several hours alone - btw, b-news expire using -e 0 doesn't expire
everything - but this is the wrong conference for that), backup the drives 
using tar, install 386/ix, re-configure drivers for hostess card and streamer,
tweak kernel, rebuild kernel, reboot OS, initialize second drive, make file 
system, start restoring the tapes of the Xenix backup to the second physical
drive under ISC (this took a long time - each tape is filled to around 50 
megabytes - and the restore (using tar xvfA /dev/tape) took around 6 hours per
tape), move the files to the correct directories and permissions then let her 
rip! 

I forgot how fast the ISC file system is over that of SCO.  Hot stuff indeed..
I also forgot to adjust ULIMIT both in the /etc/default/login AND in the 
kernel - thus my tar restore of the tapes bombed in the middle on a 4+ 
megabyte message base hash index file and had to be re-started.  I also forgot
to adjust /etc/passwd, /etc/shadow and /etc/default/login to disable the 
requirement for passwords for all logins like for my BBS callers.   Yes folks,
Unix System V is different than Xenix!  I must admit that the calls I've made 
to Bryan at ISC went well.  Bryan has answered my support calls with good 
solid information, and admits if he has to check into something more.  
Excellent support, indeed.   I did learn of the X7 update coming out that 
updates the mailer (sendmail). 

Interactive Unix made it through multiple power drops, and the file systems 
(3 of them on two physical drives) automatically recovered when the system 
rebooted.  This has happened twice over the last couple of days.  

Sendmail is not handling mail to bbs users (addressed to akcs.larry at nstar) 
correctly.  When I was running smail - the mail was tossed using the transport
file which isn't available with sendmail.  I need to get sendmail setup to 
handle messages addressed to akcs.larry at nstar to place the message in 
/user/akcs/.users/larry/mbox which seems very possible - maybe in sendmail.cf?
If I can't get this running, I'll either need to install smail under 386/ix
or replace akcs.  AKCS is one of the best BBS packages I have ever seen - and
it's link into usenet is neat - and fast.  The threading is great, when you 
go into a specific conference, messages are combined by topic instead of by
message number this way for example all the messages relating to "SCO with
RLL drives" are combined into one large item.  Not only is this easier to
read, but doesn't require a single directory entry for each and every message,
thus saving inodes which means that your drive's inode allocation will not 
need to be changed.  Karl has done an excellent job with AKCS.   The reason
I even suggested removing AKCS is that since installing it 3 months ago, I
only have maybe 6 users - which I could just as easily given shell access to.
Most callers are use to calling PCBored and TBBS machines, and even though
AKCS is very friendly and logically makes sense, they expect the traditional
type of bbs - and after one call don't return since they didn't spend the time
to learn AKCS.  

I've been amazed that the Xenix versions of AKCS, support utilities, and
news software all run just fine under 386/ix.  Xenix versions of ProYam
and utilities also run just fine.  I am wondering what additional overhead
is required to run Xenix binaries under Unix if any.  

I've been told that nn is an excellent threaded news reader.  Does it run
well under X?  I'm in the process of installing nn right now.

Next project - order X-Windows.  Bryan @ ISC mentioned that the next release 
of X (due in a couple of weeks) will support my ATI VGA Wonder board in the 
800 by 600 mode - which will be welcome.  Now I need more memory - as 4 
megabytes will be "on the border" and 8 would be ideal.  At least 1meg*80 DRAM
are down to 10.00 per chip.  Oh BTW - for those of you with the ATI VGA Wonder
board - there is a problem with the board getting in sync with some monitors 
at 31.5 due to excessive filtering which was added in order for the board to 
get the OK from the FCC.  ATI is repairing the boards at no charge - only the 
cost of shipping to Ontario (Canada).  

Futher reading about X brings forth that fact that I *really* should have a 
math co-processor to run X - now what would you get - 4 more megs of ram 
(making 8 total) or a math co-processor (the 80387 would only be use with X)?

Serial IO with my hardware configuration (25mhz '386, 4 megs of RAM, Hostess
8 port dumb board, 16450 com1 board) under 386/ix isn't as fast as with SCO
Xenix (using the internal SCO distributed drivers) - but like I mentioned - 
the file system is much faster.  I am having problems getting hardware flow
control working - and currently have the modems locked using only XON/
XOFF (USR HST 14.4kbaud carrier & Telebit T2000 are locked at 19.2kbaud, and
the Hayes V-Series (V.42) are locked (both of them) at 9600 baud).  All modems
support 1200/2400 and high speed connections.  With the above hardware under
SCO Xenix throughput was averaging 1430 (cps) on the PEP while 1640 on the
HST and 940 on the Hayes - but under 386/ix the throughput appears to be 
around 60% of that when operating under SCO Xenix 2.3.3.  I plan on getting
a multiport board with 16550ANs and hopefully using the FIFO buffers can
get the throughput back up there under ISC - either that or picking up a cheap
smart multiport board that works with bi-directional communications.  I looked
into multiport smart boards a couple of months ago when running SCO Xenix 
and never found one that had a driver that worked correctly under heavy bi-
directional communications (4 high speed modems all locked at 19.2kbaud and
using hardware flow control).  Maybe the Unix drivers work better than the 
Xenix ones supplied with boards?  Another idea is using the X5 modifications
which according to the documentation support up to 16 serial ports and include
FIFO support of the 16550AN chips.  In the X5 docs they suggest using rotating
gettydefs for the incoming modems - which doesn't allow for "pushing"
throughput on error free connections - (up to 267 cps on 2400 baud MNP 
connections), and 1450 on PEP connections.  Also, they (ISC) suggests turning
flow control OFF "since the modem DTE connection will be at that of the
carrier rate".   Why not use a single gettydef entry and let the modem handle
the "stepdown" to the carrier rate? 

PC-NFS also sounds interesting - which I can run on my 286 Fidonet server -
either that or TCP/IP between the Unix and DOS boxes.   

BTW - ISC VP/ix allows users to run multiple DOS tasks at one time in the
background (even with VGA).  Don't count on hot serial IO though, as I have
mentioned it is much slower in the native mode let alone with the additional
overhead of VP/ix.  

I consider the serial IO throughput the major problem with ISC - but feel 
that it can be handled - but still haven't found how.  Multiple 2400 baud
modems (4 to be exact) should work fine, but 4 9600 baud modems (let alone
4 19,200 baud modems) will overload the system - and connections will be 
dropping characters like crazy.  Maybe this Computone (10 mhz 80186) will
work with the new drivers?  Or maybe a dumb card with multiple 16550AN's
will cut it with the FIFO's enabled?  Maybe Jim's driver is better than
the ISC X5 modification?   Over the next couple of months I should have some
answers on these questions.  

I do miss the Xenix mail program - where I could use ~m and ~v to quote mail
- maybe I should install ELM under ix?  I wonder how ELM runs under X?  

So far so good.  I'm happy to be running Unix again, and time will be the true
test.  I might need to sell my SCO if I need both the memory and the co-
processor (how does $325 sound for 2.3.2 (with 2.3.3 update) of the '386 
release (5 months old)?   

Regards to all, and the best of the Holiday Season to you and your family.

-- 
Larry Snyder, Northern Star Communications, Notre Dame, IN
uucp: root at nstar -or- ...!iuvax!ndmath!nstar!root