Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!usenet.ins.cwru.edu!neoucom!wtm
From: wtm@uhura.neoucom.EDU (Bill Mayhew)
Newsgroups: comp.dcom.modems
Subject: T-25500 with Mac A/UX
Summary: The best flow control is no flow control
Message-ID: <1990Jul02.171637.6630@uhura.neoucom.EDU>
Date: 2 Jul 90 17:16:37 GMT
Distribution: na
Organization: Northeastern Ohio Universities College of Medicine
Lines: 52

When A/UX, or really virtually any uucp implementation, is used
with a T-2500 modem in PEP mode iwth uucp protocol spoofing
enabled, the modem will force the g protocol to be selected.

The g protocol is inherently self-pacing, so flow control is not
needed.  As implemented in the T-2500 et al, a window size of 3 is
specified.  This means that the transmitting end will send up to 3
packets before waiting to receive an ACK from the receiving end of
the conversation.  I believe that the packets each contain 64 bytes
of data plus checksum and header to result in 77 bytes per packet.
This means that the receiving computer has to be able to keep up
with brief bursts of full speed data for about 231 characters.
Virtually all machines that I have seen are up to the job.

The T-2500 has what seems to be about a 32Kbyte or so buffer.  I
have observed my Trailblazer continuing to dump data into  my
computer even after the call has actually terminated.

In my case, I use a TB+  with a Unix PC.  I have hardware  flow
control via the RTS/CTS leads enabled because the tty driver for
the Unix PC will permit that non-standard used of the leads for
flow control.  Normally, the flow control is never asserted for
PEP-PEP mode connections.  The only time I have actually observed
flow control is when my machine is sending a large file to a machine
that has called into me at 1200 or 2400 bps.

Whether or not you can use hardware flow control with A/UX depends
on the tty driver.  I can't tell you right now, but could in the
near future.  I have a II-cx with A/UX on order and expect it to
arrive any now!

One thing you don't want is xon/xoff flow mixed with uucp.  That
will cause uucico to hang big time.  Also, I have experimented
with specifying the f protocol and using the Trailblazer in
non-uucp-spoofing-PEP mode.  You don't want that either.  I've
experienced consistent over-runs with the f protocol.  In case you
wondered, f is a non blocked protocol that transmits an entire file
at a time with the assumption that the underlying transport
machanism is absolutely error free right up to the time the data is
actually in the machines RAM.  Serial cables don't qualify, even if
there is a direct connection sans modems.  Ethernet or something
equivalent is really what is required.  You can experiment with
specifying the protocols in some uucp versions by placing a ";f",
for instance, appended to the baud rate field in L.sys or Systems.
Ther is no standard implementation, naturally.

==Bill==
-- 

Bill Mayhew  Northeastern Ohio Universities College of Medicine
Rootstown, OH  44272-9995  USA    phone: 216-325-2511
wtm@uhura.neoucom.edu   ....!uunet!aablue!neoucom!wtm