Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!highspl!fithp!mhw
From: mhw@fithp (Marc Weinstein)
Newsgroups: comp.sys.3b1,unix-pc.uucp,unix-pc.general
Subject: The "Final" Word on 3b1 HFC
Message-ID: <1991May18.175656.2858@fithp>
Date: 18 May 91 17:56:56 GMT
Distribution: na
Organization: Weinstein Consulting
Lines: 67

Well, it is almost time to give up.  Thad's article seemed to sum it up
quite nicely.  It appears that HFC, with some playing on our part, works
just fine when sending data out, but is worthless on incoming data.  Here's
what we saw...

As we left our heroes in the last episode, they had used two Prac Periph
modems, talking using 9600 baud V.42bis, with port speeds set to 19200.
It took a separate port conditioning daemon, running all the time and
reapplying port settings every ten-or-so seconds, to get HFC to go on
and stay on.  Don't trust the gettydefs settings, and don't think that
uucico will apply HFC.

With both of our port speeds set to 19200, we attempted to send some 
files.  First, we sent compressed news batches.  Oh my God!!!   It worked!!!
They went through just fine, showing a transfer rate of 1079 Bps.  This
is definitely an improvement over the 959 Bps we typically see with
9600 baud port speeds.  We were ecstatic!  Then, we tries sending something
which was NOT already compressed - we used the 3.51m kernel - compresses
pretty much using V.42bis.  Total failure!  The sending system spit out
a stat showing file transfer at over 1800 Bps, but the receiving system
NEVER saw the Completion message in UUCP.  It never recognized the file
coming in.  We also tried MNP5 - same results.

This makes sense.  If the data to be transferred is already compressed,
then there's not much the modem compression will add, so the throughput
at the 3b1 port will be very close to the throughput on the phone line,
which is 9600 baud, or a bit higher when the start/stop bits are removed.
So, the system limits itself to some data transmission rate over the port,
and the 3b1 seems to be able to handle it.  Then, when you pass it something
which is NOT compressed, V.42bis can really crunch it, and therefore the
DCE-to-DCE rate of transfer ends up being much slower than that at the port,
and the port can't keep up.  1800 Bps is fairly close to the 19200 
capability, and the PC loses characters.  So, if there were some way to
always limit the transmission rate between modems, a 19200 port speed 
could probably be maintained.

Now, to adequately demonstrate that HFC works in one direction, we now
set one of the port speeds to 9600 baud.  Now, if the system with the
9600 baud port speed sends data to the one with the 19200 port speed,
then the port speed on the sending system is limiting the rate of 
transfer - everything works fine.  If the receiving system is the one
with the 9600 port speed, then the following happens.  The modems
continue to talk at the same rate, but the modem at the receiving end
starts to buffer incoming data, since the data is arriving faster than
the port can offload it, and eventually the modem detects pending
overflow.  So, the modem asserts HFC, which is detected by the sending
modem, which asserts HFC to the 3b1.  Now, the port at the 3b1 detects
CTS being negated, and it stops the flow of data.  Fine!  Everything
works ok.  And, in the example I gave above where we sent compressed
batches with a port speed of 19200, the SENDING modem's buffer starts
to fill up, because the port is feeding it data which is can't send
to the remote modem fast enough, and the modem eventually asserts HFC,
which the outgoing port detects and limits the flow of data.

So, the ideal would be to arrange a setup where compression is disabled
for the sending of already-compressed files (since the modem compression
would cause the rate to go too high) while for less compressible files
the compression would be enabled, thus helping the throughput.  I'm
not sure if this can be achieved, so we're close to giving up.  We still
plan to try the UUCP g protocol with 19200 - perhaps the ACK nature of
the protocol would keep the throughput low enough to allow the 3b1
to keep up.

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