Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!public!thad
From: thad@public.BTR.COM (Thaddeus P. Floryan)
Newsgroups: comp.sys.3b1
Subject: Re: 19.2K on a 3b1
Message-ID: <2225@public.BTR.COM>
Date: 27 Mar 91 21:36:28 GMT
References: <10499@uwm.edu> <2214@public.BTR.COM> <35907@ditka.Chicago.COM>
Distribution: usa
Organization: BTR Public Access UNIX, Mountain View CA
Lines: 68

In article <35907@ditka.Chicago.COM> kls@ditka.Chicago.COM (Karl Swartz) writes:
> ... a variety of things claiming 19,200 works fine on his 3B1 with no loss
> ... of characters and/or data.

That's good for you, but I'm aware of at least 3 other people here in the
Bay Area with exactly the same problems, all of whom have configured their
3B1 systems and T2500 modems independently from the others, and all are
experiencing the same problems.

In my case, the kernel is 3.51m with everything except the ksh "upgrade",
sports 3.5MB RAM, and the modem is a T2500 with GF7.00 ROMs.  Problem occurs
with the onboard tty000 and with any EIA/RAM Combo port tty001-tty004.  The
problem occurs WITH and WITHOUT the modem (i.e. direct into another 3B1 with
the same configuration), so I'm not blaming Telebit.  The problem also occurs
direct-connection to other systems, and manifests itself ONLY with input to
the 3B1.

19,200 lossage also occurs using Ymodem-BATCH (sb and rb) and Zmodem (sz and
rz), so it's not specific to HDB uucp.

With one series of tests INTO an Amiga (with 68020/68881), its (the Amiga's)
hardware flow control very clearly (monitored using alternately a bi-color
LED breakout box and a Benedict Computer Systems Data Line Monitor) was doing
the "right" thing.  Turning around and feeding back into the 3B1, it was VERY
clear the 3B1 was NOT asserting its hardware flow control with the same
consistency as the Amiga was, hence the data lossage; the problem into the
3B1 was also observed during uucp transfers both hardlined and over a modem
connection (from other 3B1 systems, and from HP-UX/Sun/other systems).

Among the test parameters was the altering of NCLIST and NTTYHOG (via ktune)
to no apparant benefit; i.e. the 3B1 consistently would lose characters using
hardware flow control at 19,200.  And using X-ON/-OFF flow control is NOT an
option since binary data is being transferred.  (And, yes, I did reboot after
each ktune change :-)

Since I doubt your 3B1's hardware is "different" from mine, I'm at a loss to
explain why Karl claims 19,200 works fine and I assert it doesn't (on the 3B1).

During the uucp tests, 19200 baud output from the 3B1 was clearly evidenced
by continuous transmission.  What occurs during INPUT is the first 6K to 7K
of chars come in just fine, then *POOF*, everything falls apart; during uucp
input transfers, there'd be several seconds delay with no data transfer,
followed by a "packet" coincident with an "Alarm n", more delay, another
incoming "packet" coincident with "Alarm n+1", ad infinitum, causing the 75 cps
effective input rate.  With Ymodem or Zmodem, the incoming chars would be OK
for the first 6K up to sometimes the first 24K or so, then, *POOF*, CRC errors
or "packet too long", followed by a wait, followed by a retransmission, etc.

> If you can't dazzle them with brilliance, baffle them with bullshit,
> eh Thad?  You undoubtedly have provided a lot of help to numerous
> UNIX PC owners, but when I read nonsense like this (unfortunately not
> unique to this occasion) I really have to wonder.

If the problem was ONLY with modem transfers, then I'd post the T2500 reg
settings and ask for help.  But since it's also with hardlines and with ALL
protocol transfers (uucp, zmodem, ymodem, etc.), the nature of the problem
must be a kernel and/or hardware limitation.  And it occurs even when pulling
ALL expansion cards (except the EIA/RAM Combo card) out of the system, so it's
not a function of the presence/absence of Ethernet, StarLAN or VoicePower.

OK, so what's YOUR explanation for the problem on at least 4 other peoples'
systems?

I don't mind having my assertions being proven wrong, but all evidence and
test data I have (and anecdotal evidence from others) supports my contention
the 3B1 with hardware flow control cannot support 19,200 baud correctly.

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