Newsgroups: comp.sys.3b1
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!n8emr!colnet!res
From: res@colnet.uucp (Rob Stampfli)
Subject: Re: The "Final" Word on 3b1 HFC
Message-ID: <1991May19.062144.25034@colnet.uucp>
Organization: Little to None
References: <1991May18.175656.2858@fithp>
Distribution: na
Date: Sun, 19 May 1991 06:21:44 GMT

Just to add another twist to the already sordid tale of woe regarding
hardware flow control on the Unix-PC....

I have a V.32 modem connected to my PC, and it seems to work just fine sans
HFC with uucp g.  Well, almost -- it does tend to resync a lot when I am
getting news, but I have always attributed that to the "known" problems of
talking to a TB 2500 in V.32 mode.  The other day, I connected a terminal to
another spare port.  Lo and behold, I discovered that any activity that
resulted in significant output to the terminal completely hosed the uucp
transfer in progress on the modem at the time.  I tried the following with
no noted improvement:

1. Swapped the modem and terminal between tty000, tty001, and tty002.
2. Changed the physical location of the serial card.
3. Exchanged serial cards.
4. Exchanged the Unix-PC with another different machine.
5. Changed the baud rate of the terminal from 9600 down thru 300.
6. Changed the rs232 cable to the modem.

The only thing that may have affected the problem was applying the io 4/60 ->
1/60 sec serial i/o patch.  Applying this patch *seemed* to make the problem
harder to reproduce.

Things I have not tried are:

1. Reloading and testing with 3.5.  (I am on 3.51m.)
2. Swapping modems.

Note that I can spool up two outgoing uucp transfers -- one via the modem,
and one via a hardwire link -- without problems.  The only time this problem
manifests itself is when the modem is receiving data, and another port is
sending data.

Now, I wonder.  Could something in that part of the io subsystem that is
responsible for processing the outbound queue be locking out interrupts
long enough for the incoming stream from the modem to overrun?  If this is
true, then this problem and the HFC problem might be related in that they
are being caused by dropped characters due to either the hardware not being
robust enough to accomodate 9600 baud, or a software problem in the io
subsystem.  Perhaps the HFC problem has nothing to do with HFC.  And, maybe
the problem with uucp g I notice occasionally is the incoming packets being
corrupted by the ACKs.

I have nothing substantive to prove this.  I'm just casting about looking
for answers.  And it is too late to continue, so I am going to bed.
-- 
Rob Stampfli, 614-864-9377, res@kd8wk.uucp (osu-cis!kd8wk!res), kd8wk@n8jyv.oh