more on the HFC saga

[Marc Weinstein]

To all those who are still interested...

We've discovered quite a bit over the last few weeks about Hardware Flow
Control on the 3b1.  If the below findings are common knowledge to some,
such is life.  If anything is incorrect, please post a correction!

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 V1.31 PROMs from
them, and they help - 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
Control bit (CTSCD) was NOT getting set!!!  Even if we checked immediately
after calling the /etc/hfc_ctl program, the bit was NOT set.  So, we wrote
a program to set the CTSCD bit and did some experimentation.  Here's what
we found...

First and foremost, the /etc/hfc_ctl program appears to ENABLE HFC, not turn
it on.  It seems that this program (somehow) configures the driver so that
it pays attention to the CTSCD bit on the port.  The trick is to get this
bit turned on.  The standard getty (/etc/getty) appears to recognize the
'CTSCD' string in the gettydefs file, but the HoneyDanber uugetty does not.
It, instead, recognizes the string 'HFC', which should be placed in the
gettydefs entry.  It should be placed in both the second and third fields
of the entry, to make sure it gets turned on during the entire connection.

However, the uugetty program doesn't apply these settings until a connection
is made.  This means that the 'idle' condition of the port is NO HFC turned
on.  If you happen to try an outgoing call at this time, uucico doesn't set
HFC, it just inherits the current state of the line.  So, the outgoing call
will not have HFC active.  In fact, if the HFC bit is set and you kill
uugetty, when it restarts the bit will be cleared.  The solution (if
that's what you can call it) was to write a program to condition the port,
and have the program do its stuff right after uugetty has started.  The
program is actually invoked in the background from a script called from
the inittab (rather than directly calling uugetty) - it gives uugetty a
certain amount of time to get settled, and then it attempts to condition
the port.  The script then exec's uugetty.  In this way, we can make sure
that the HFC bit will be set during the 'idle' state.  However, this
obviously implies that if an outgoing call were attempted before the
program finished execution, there could be an interval where HFC is not on.

The other thing we discovered was that uugetty doesn't seem to recognize
19200 baud.  We tried using the strings 'B19200' and 'EXTA' in the
gettydefs entry, and yet our program which prints out port settings still
showed B9600 as the baud rate.  So, we added this capability to our port
conditioning program.

We also installed the patch to the kernel which offloads characters from
the interrupt buffer more often - this patch changes the polling of the
interrupt buffer from once every 4/60th of a second to once every 1/60th
of a second.

Unfortunately, with all this in place, we STILL can't get reliable
connections with a port speed of 19200.  We're seeing a very strange
problem right now, where if we try to login, even manually, with the
port speed set to 19200, we always get 'Login incorrect', even though
the login name we type in is echoed back at us as we would expect.  And,
it appears that changing the way the 'init' program starts uugetty is
not without its flakiness - uugetty doesn't get restarted after an outgoing
call (it should, since the modem is configured to reset when DTR goes low).

The last possibility would be to switch to the new getty which was posted
a while back.  We tried using it and saw all sorts of errors.  Has anyone
gotten this working??  If so, could they post the source they ended up
with?

Well, if anyone can offer any advice, we'd welcome it.  I'd love to hear
how those who say they got 19200 HFC to work actually did it.  We're
beginning to think that, yes, HFC does work, but it doesn't matter because
the 3b1 isn't fast enough to administer it properly.  By the time it
detects overflow and reacts to it, it's too late.  Complete conjecture
on our part, though...

-- 
Marc Weinstein
{simon,royko,tellab5}!linac!fithp!mhw		Elmhurst, IL
-or- {internet host}!linac.fnal.gov!fithp!mhw