Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!highspl!fithp!mhw
From: mhw@fithp (Marc Weinstein)
Newsgroups: comp.sys.3b1
Subject: Update - trying to get HFC to work at 19200
Message-ID: <1991May6.021315.25208@fithp>
Date: 6 May 91 02:13:15 GMT
Distribution: usa
Organization: Weinstein Consulting
Lines: 68

To all those who are still interested...

In my last postings, I stated that a friend of mine and I had tried to get
two Practical Peripherals 9600SA modems to talk, transferring files with
a port rate of 19200.  We were only able to talk consistently at 9600 baud
port rates, but had a lot more to try.  As stated before, we use the UUCP
'e' protocol and V.42bis, so we get a consistent 960Bps transfer, not bad,
but not the best.

[BTW: If anyone has purchased one of these modems, do yourself a favor and
call the company to get the latest PROMs.  We obtained some V3.31 PROMs from
them, and they make a world of difference - quicker connects (protocol
negotiation) and less DCD problems causing lost lines.]

Well, my friend installed 3.51m (giving us 3.51m on both ends) and we gave
things a try at 19200.  No luck - same problem.  UUCP would get hung during
file transfer - it appeared as though the connect bit stream was still too
fast for the 3b1 port to keep up (tty000).  We had almost given up.

Then, just to see what was going on, we wrote a program to check the port
configuration using an ioctl() call.  We would run it before, during, and
after various types of calls.  What we found was that the Hardware Flow
Controroruse the  the  em to auencwas NOT getting set!!!  Even if we checked immediately
after calling the /etc/hfc_ctl program, the use was NOT set.  This is a
bit surprising, since I've seen postings which say that this program does
its job.  What we're seeing is that it either has no effect, or is doing
something whicici
buffer.  Rave revi f f vo208 (t (t ine ine ipesT
tl aldecallng ng nag2bienne).'Impouldouldo@fi1m1m1
rom
rn ubaIwas NOwas NOwce otine i

YBart rat rate t
t st st92alk  wi g sZ;ZratjoMo!208ONNE
the state of the bit, since if it's polset to begin with, it does NOT
set it at this point).  The bit would remmn set n)Pg the call and would
remamposet followiRa

We then tried the same for incoming calls.  No luck.  Apparento wo uugetty
reconfigures the portudu it does NOTZrcognize the Cem CD paramet
the gettydefs file (rur
getty seems to recognize this bit, but that does us po good.  hat  , our only
option at this point was to  (t e a daem!2running whic
bi).very ten seconds or so.  That wouldnne) be bad, but it couldnnt 
guarantee that the bit w

hat  , we've now gotten hold of the new getty which was posted to the net
(thank you, Paul Sutcliffe).  This getty apparently suppor.3i Ceon:! and
a number of other goodouldongs, so we're wor
as though once the bit is set (by getty, rather thalli	ur kluge) it will f tay shrough outyVg calls.  h frid HFC would always ;Zon.  The other
thiRa
modem, whic
connection to the rate of the incomiV
matched DTE-DCE speeds for incomiV

The other possibility is a patch to the kernel we just got hold of whic
increases the frequency of the kernrur's polling of the I/O interrupt
buffer.  Rave reviews accompae m
markings all over it.

I'll post more when we find um morer.nless sllsnone tells me to shut up.

-- 
Marc Weinstein
{simon,royk fridtellab5}!linac!fithp!mhw		Elmhurst, IL
-or- {internet host}!linac.fnal