19.2K on a 3b1

[Thaddeus P. Floryan]

In article <10499 at uwm.edu> peter at csd4.csd.uwm.edu (Peter J Diaz de Leon) writes:
>
>Does anyone know if it is possible to run the 3b1 serial port
>at 19.2K bps.
> 
>I need to transfer about 45MB of data between a ATT 3b1 and a ATT 6386EWGS
>system.  If anybody has any other ideas I on how to do it my ears are open.
>[...]

Man, I've been swamped with work the past 4 weeks and am about a month behind
on usenet postings, but this question from Peter immediately captured my
attention since I've been fighting the same problem myself.

As a quick answer, I'd give a qualified "yes".  BUT, it is mandatory that one
use hardware flow control AND there's no "standard" software for the 3B1 that
will correctly support hardware flow control and 19,200 baud.

And before you say bullsh*t, please note that I've spent HUNDREDS of hours
testing this using Data Line Monitors and special software on other computers
connected to my 3B1 systems.

Even WITH hardware flow control, I've been forced to run my Telebit 2500 locked
at an interface speed of 9600 baud to assure reliable data exchange.

I have tested modems, StarLAN, and direct hardlined connections to the 3B1 all
in the hopes of getting reliable 19,200 data transfers.  The {rz,rb,rz} and
{sz,sb,sx} programs suck dead bunnies through a straw at 19,200; the same is
true for EVERY other method I've tested, including HDB's uucico, with but one
exception:  "cat" and "cp".

The ONLY method I've achieved reliable 19200 data transfers with the 3B1 in/out
the serial ports and/or StarLAN NIU is using hardware flow control and the
commands "cat file" and "cp /dev/tty file", and even then only after explicitly
disabling ALL X-ON/-OFF flow control (e.g. stty -ixon) and disabling all input
echoing (e.g. stty -echo -echoe -echok) [and, of course, enabling the hardware
flow control on the respective port by: /etc/hfc_ctl +/dev/tty???).

To say the least, I'm NOT pleased.  I'm starting to come to the conclusion the
3B1 can support 19200, BUT that much of the extant software does "something"
to foil successful operation.  I'm still running tests to completely
characterize the problem and will post when I have done so.  Sigh  :-(

Unless Peter's files are ASCII and can be transferred along the lines of what
I've stated above, his best courses of action are either to Ethernet the files
or operate at a lower baud (start the stuff on Friday night and let it run all
weekend).

When 19200 works correctly, one can count on 6MB per hour, half that for 9600.
Thus, 45MB would require (roughly) 8 hours at 19200 and 16 hours at 9600.

The ONE thing that's really p*ssing me off on the 3B1 is that I can transfer
uucp OUT just fine at 19200 with hardware flow control (getting 1800+ in the
uucp xferstats), but I'm getting the distinct impression that hardware flow 
control doesn't work as well on input as it should ... it's "almost" as if HFC
was mono-directional EXCEPT for the fact that use of both a breakout box and a
Data Line Monitor has verified that HFC is being used (but probably not as well
as it could be; sigh, without source ...... )

For the record, at 19200 baud and HDB UUCP, my send rate would be 1800+ and
my receive rate would be 75 cps.  Yes, 75 cps, due to retransmission delays.
At 9600 baud, I both send/receive around 870 cps.  Both cases with HFC and
the same Telebit T2500 modem whose only change is the serial data rate.

Several more tests yet to be run are putting the modem on StarLAN (via an
RS-232 NAU) and on an Ethernet terminal server.  SOMETHING has got to work,
cause I sure as hell don't want to have to buy a 50 MHz 68040 computer solely
to be used as a uucp transmit/receive point.  Damn, even one of my present
products using an MC6803 (yeah, an 8-bit computer) with MC68681 DUARTs can do
both 19200 and 38400 on three (3) serial ports simultaneously continuously
with 100% error-free data transfer and NO protocols.  Sheesh.

More later ... enough rambling for now, gotta keep my blood pressure down.

Thad Floryan [ thad at btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]