[comp.dcom.modems] T-25500 with Mac A/UX

wtm@uhura.neoucom.EDU (Bill Mayhew) (07/03/90)

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

rmtodd@uokmax.uucp (Richard Michael Todd) (07/04/90)

wtm@uhura.neoucom.EDU (Bill Mayhew) writes:

>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.
  Hmm, that's strange.  I don't think that's supposed to happen--the sender 
is supposed to wait around until the receiver sends the "file OK" message
("CY" or something like that--I haven't looked at uucp innards in some time..)
Certainly, I've never seen it happen on my T1000 connected to my Mac IIx.
There's a sizable buffer there, but it empties at the end of each file...

>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!
  For practical purposes, you can't use hardware flow control on a Mac with
A/UX, but the reasons have nothing to do with the tty driver.  The problem is
that the Mac serial ports share the same design flaw as the serial ports of
the Encore/Xylogics Annex terminal server (recently discussed in comp.sys.
encore), namely, there aren't enough wires coming out of the serial port. 
Both the Mac and the Annex give you only two control lines, which can be 
used for either flow-control *or* modem-control (carrier detect, hanging up
under DTR control), but not both.  The driver software can't do anything about
it.  You're stuck--either you choose hardware handshaking, or you choose
the ability to hang up the modem under computer control.  
  My experience is that a T1000 (the 9600bps max throughput little brother
of the T2500) works well enough with a Mac IIx without flow control.  Alas, 
I've never had the chance to play with a full-speed Trailblazer on this 
system... 
-- 
Richard Todd   rmtodd@chinet.chi.il.us  or  rmtodd@uokmax.ecn.uoknor.edu  
"MSDOS is a Neanderthal operating system" - Henry Spencer