Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!ntg!dplatt
From: dplatt@ntg.com (Dave Platt)
Newsgroups: comp.sys.mac.comm
Subject: Re: zmodem and MNP compression
Message-ID: <125@goblin.ntg.com>
Date: 30 Apr 91 18:45:36 GMT
References: <1991Apr29.153954.1661@magnus.acs.ohio-state.edu> <1991Apr29.193312.16542@agate.berkeley.edu>
Organization: New Technologies Group, Inc.  Palo Alto CA
Lines: 53

In article <1991Apr29.193312.16542@agate.berkeley.edu> labc-1ic@e260-1f.berkeley.edu (Willy S. Liao) writes:

>Well, I use Zmodem with MNP 5 and it does work, sort of.  I have to watch out
>for nasty flow-control problems because the modem I'm connecting to can't
>pass on flow-control signals to the UNIX host (so I'm told).  Anyway, with
>sz 3.07 I've gotten over 300 cps on text files routinely (I usually use
>only MNP 4 when transferring .sit or .cpt files).  If flow control is a
>problem on your system, try something like 'sz -w 1536', which means
>"do not send more than 1536 bytes unacknowledged" so if your Mac does
>something under MultiFinder which hogs the CPU, the UNIX host will stop
>sending after 1536 bytes have gone through w/o a reply from your Mac.

I've had similar results, running the ZMODEM protocol over a modem-link
which uses V.42 error control and V.42bis compression.  I've found that
it's not a good idea to try to use XON/XOFF software flow control...
although the ZMODEM protocol is smart enough to avoid use of these
characters in its packets, Unix systems frequently won't honor XON/XOFF
flow control when they're sending/receiving data in "raw" mode.

To make matters more annoying, many Unix system's don't honor RTS/CTS
hardware flow control... meaning that there is _no_ reliable out-of-band
flow control available!

I've found that the ZMODEM "sliding window" mode, invoked by the -w
option in sz and the "window size" option in ZTerm, is really the ticket
to getting ZMODEM to work well over modems that support error control
and/or compression.  It costs a percent or so of line throughput, but it
almost entirely eliminates data overruns and similar nasty things.  It
implements a true end-to-end flow control within the ZMODEM protocol,
and is thus more reliable than flow control that's implemented solely at
the host-to-modem level.

Using a V.32 modem with V.42bis compression, I've seen ZMODEM throughput
as high as 2500 character/second when sending ASCII text files.

>Anyway I do recall reading in my modem manual that xmodem absolutely does
>not work without XON/XOFF flow control, so this implies it will never work
>with MNP 5 & RTS/CTS.

It's the other way around, actually.  XMODEM requires a clean,
transparent 8-bit data link... modems which implement XON/XOFF flow
control will "eat" these characters, corrupt the XMODEM packets, and
cause the file transfer to abort.  XMODEM is compatible with both MNP 5
and RTS/CTS flow control.  However, if you're using vanilla XMODEM
(128-byte packets), MNP of any persuasion will probably hurt more than
it helps... it introduces some delay into the transmission, and
increases the end-of-packet turnaround delay... already a bottleneck in
many situations.

-- 
Dave Platt                                                VOICE: (415) 813-8917
              Domain: dplatt@ntg.com      UUCP: ...apple!ntg!dplatt
 USNAIL: New Technologies Group Inc. 2468 Embarcardero Way, Palo Alto CA 94303