Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!mips!apple!netcomsv!gandrews
From: gandrews@netcom.COM (Greg Andrews)
Newsgroups: comp.dcom.modems
Subject: Re: Trailblazer problem
Summary: It's just a flow control problem
Message-ID: <1991May16.054726.22064@netcom.COM>
Date: 16 May 91 05:47:26 GMT
References: <1991May14.213151.8741@vpnet.chi.il.us>
Sender: netnews@netcom.COM (USENET Administration)
Distribution: na
Organization: Netcom - Online Communication Services  UNIX System {408 241-9760 guest}
Lines: 51

In article <1991May14.213151.8741@vpnet.chi.il.us> lisbon@vpnet.chi.il.us (Gerry Swetsky) writes:
>Vpnet uses two Trailblazer Plus'.  We recently upgraded both of them 
>to ROM version BC7.00.  Here's the problem.  Whenever someone calls us
>at 2400 baud and tries to cat a file, the modem loses sync after about
>2,000 characters or so and from there on the result is garbage.  We run 
>a locked interface at 19,200.                                    ^^^^^^
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>S61:000 S62=003 S63=001 S64=000 S65=000 S66:001 S67=000 S68:002 S69=000 
>                                        ^^^^^^^         ^^^^^^^
>
>For grins, here's our gettydefs (locked interface).  I've inserted 
>C/R's to make it more readable.....
>
>19200N8# B19200 OPOST ONLCR TAB3 BRKINT IGNPAR IXON IXANY ISTRIP 
>ECHO ECHOE ECHOK ICANON ISIG CS8 CREAD # B19200 OPOST ONLCR TAB3 
>BRKINT IGNPAR IXON IXANY ISTRIP ECHO ECHOE ECHOK ICANON ISIG CS8 
>CREAD HUPCL #login: #19200N8
>

You're running a locked interface speed at 19200 bps, and the caller is
dialing in at 2400 bps.  In other words, the computer pours data into the
modem EIGHT TIMES FASTER than the modem can empty itself out.  The modem
has been told to use (full) duplex RTS/CTS flow control, but I see no
evidence that the computer will obey it.

After the modem's buffer gets full, it tries to tell the computer to stop
(you can even see the CTS light turn off), but the computer isn't listening
and it overruns the modem's buffer.  Guess how big the TrailBlazer Plus
modem's input buffer is?  Yup, a little over 2000 bytes.

It certainly looks like it's a flow control problem.  You can't look to
your uucp results because they won't necessarily be the same as catting
a large file.  Most uucp implementations still use a three packet window
with sixty-four bytes in each packet.  That means only 210 bytes would be
sent before the sender halts - far less than the 2000+ bytes the modem can
handle.  If you're using uucp spoofing, then the whole thing goes out the
window anyway - the modems don't need hardware flow control to work properly
in spoofing mode.  They use the protocol itself to perform flow control.

You can test the flow control operation yourself - just dial in at slow
speeds and watch the host modem's CTS and SD lights.  They are conveniently
next to each other.  If hardware flow control is working properly, the
lights will be in sync (SD will go off when CTS goes off).  If not, then
SD will continue shining even when CTS turns off.

-- 
 .------------------------------------------------------------------------.
 |  Greg Andrews   |       UUCP: {apple,amdahl,claris}!netcom!gandrews    |
 |                 |   Internet: gandrews@netcom.COM                      |
 `------------------------------------------------------------------------'