Xref: utzoo comp.dcom.modems:3317 comp.mail.uucp:2727
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!neoucom!wtm
From: wtm@neoucom.UUCP (Bill Mayhew)
Newsgroups: comp.dcom.modems,comp.mail.uucp
Subject: Re: Problems with HDB uucp xfer
Summary: It is fixable!
Message-ID: <1488@neoucom.UUCP>
Date: 3 Feb 89 03:09:22 GMT
References: <257@utgard.UUCP> <173@n8ino.UUCP> <24285@amdcad.AMD.COM>
Distribution: na
Organization: Northeastern Ohio Universities College of Medicine
Lines: 87


Several people have recently reported complaints about uucico
timing out with alarms when dialing into a site that only supports
slow connections (1200 or 2400 buad) dialing from a Trailblazer
modem.


This problem is can be fixed.  The problem crops up apparently due
to the buffer management scheme in the Trailblazer.  When you
initiate the call to the remote site in non-PEP mode, you lose the
nfity intelligence built into the modem for pre-acknowedging the
uucp g protocol from your originating modem.  .. but you don't lose
the buffering in the modem.

The problem most likely happens when your machine has a higher baud
rate talking to the modem than the baud rate of the data link.
You might see bugs at the host operating at 2400 baud and the modem
also at 2400 with MNP enabled on a poor line lowering the aggregate
throughput to something less than 2400 baud between ends.

Apparently, the Trailbazer is pretty conservative about buffer
management when operating in non-PEP mode.  The trailblazer seems
to send flow control back to your host when the trailbalzer buffer
has about 100 characters queued for transmission.  The protocol
start-up following the Shere=mach_name exchage is long enough to
scare the trailblazer into flow-controlling your host.  If you have
set registers S58 and/or S68 to use Xon/Xoff or Enq/Ack in-band
software based hand shaking, your host will gag on the flow control
character and go out to lunch 'til the alarms time out.

The good news is that the basic g protocol without sliding windows
uses data packets of 70 characters, so there is in reality very
little (in fact no) chance of over running the buffer in the
trailbalzer because your host will wait for the acknowledgement
from the rmote host before sending the next packet.  In effect the
protocol is self-regulating, not needing flow control.

There are two tacks that you can take to solve the problem:

1.  Set up your uucp chat script to disable flow control.  You need
to set S58=0 and S68=0.  If you need flow control for interactive
sessions later on, on the same line, program S52=2 to reload
operating parameters on drop of DTR lead.  Program the NVRAM to
set S58 and S68 seasoned to taste for the interactive sessions.
Make sure that your modem has a cable with leads 1,2,3,4,6,7,8 and
20 going to your host port so that when uucico toggles DTR at the
end of the call that the NVRAM parameters will reload.

2.  Talk to your modem at a baud rate less than or equal to the
remote modem and prefereably don't use MNP protocol.  Set S51=255
to enable autobauding of the host interface.  Make sure that you
start all your chat scripts with A\pA\pA\pA\pA\p.  At lower buad
rates, it might take up to five As for the modem to figure out the
interface speed.

I use method #1, and have had no problems calling into slow sites
with it.  I use method #1 beuase my trailbalzer also has to support
incoming calls with uugetty.  You could program uugetty to do the
round-robin baud switching via the break key, but there are 6 buad
rates that must be stepped through and it is also difficult to
explain the procedure to neophyte l'users in the acctg. dept. and
the like that are scared enough just at the mention of the word
modem, let alone "buad rate" and "break".  It's much easer to lock
uugetty at 19.2K interface and leave the modem to do the
translation.

Before I got HDB and uugetty, my trailblazer was strictly dial-out
under the icky generic System V uucp that doesn't have uugtetty.  I
used method #2 with good success in that case.  Method #2 is
probably a little easier than #1, but #1 lets you get a lot more
mileage from your modem by also supporting dail-ins on the same
line.

I think it would be real handy if Telebit would publish a hint
guide for setting up with uucp.  It took quite a bit of head
scratching when I first got the trailblazer to figure everything
out.  Things like the effects of S58/S68 can be pretty subtle, and
hard to pin down without using a serial line analyzer.  I've been
using trailblazers here for about a year and a half now, and it has
most definitely been worth the work.  I've saved a lot of money in
LD charges and generally improved the convenience of the system.


I hope this clarifies a couple of things,
--Bill
  wtm@impulse.UUCP
  ...!lll-winken!scooter!neoucom!impulse!wtm