Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!apple!ntg!dplatt
From: dplatt@ntg.com (Dave Platt)
Newsgroups: comp.sys.mac.comm
Subject: Re: ZTerm transfers (again...)
Message-ID: <850@goblin.ntg.com>
Date: 1 Jun 91 19:22:31 GMT
References: <009496DA.C7E09C00@uclapp.physics.ucla.edu>
Organization: New Technologies Group, Inc.  Palo Alto CA
Lines: 86

In article <009496DA.C7E09C00@uclapp.physics.ucla.edu> price@uclapp.physics.ucla.edu (John Price) writes:

>OK, I can deal with that.  It wants multiples of 256.  I have no idea why, 
>but now I at least have a handle on how to affect the program's operation.  
>I found that the larger I made this number, the faster I was able to 
>transfer data.  This effect seems to flatten out with a window limit of 
>about 4096 (it's currently set to 16384).

I have a hunch that any value over 4096 is treated as a 4096-byte limit.
I use a 2048-byte limit when uploading and downloading via a V.32 modem
at 9600 bps... this seems optimal for my configuration.

>Now, my questions to Dave Alverson (or anyone who has more of a clue about 
>this than I do - that shouldn't cut too many people out  :) are the 
>following:
>
>	1: What is the "subpacket length"?

The ZMODEM protocol divides your data into packets, each one of which
contains a certain number of bytes of data.  Each packet has a header,
and a trailer which includes a CRC code to detect errors.

If the receiver of a ZMODEM transmission detects a CRC error in a
packet, it tells the sender to back up and retransmit data from where
that packet started (in the original file)... this is the "ZRPOS"
message you're seeing.  Any additional packets which were "in transit"
are discarded by the receiver.

If you have a noise-free connection, it helps to use large packet sizes,
because there's a fixed amount of overhead in each packet.  If you have
a noise-prone connection, smaller packets tend to be better... there
will be less chance that any particular packet will be corrupted by line
noise, and the protocol will spend a bit less time "backing up" and
retransmitting (and discarding large packets which were "in transit" at
the time of the error).

>	2: What is the "window limit"?

Normally, ZMODEM operates in a "streaming" mode... the sender transmits
data as fast as possible, the receiver swallows it as fast as it can,
and the receiver sends back signals only when data isn't received
properly.  This mode has the least overhead, and the fastest
transmission rate, _if_ the receiver is able to keep up with the sender.
If the receiver _cannot_ keep up with the sender, the sender will
occasionally "over-run" the receiver's buffers;  data will be lost, and
the receiver will have to tell the sender to back up and retransmit.

A convenient way to avoid this is to use the "sliding window" mode...
controlled by the window-limit field in ZTerm, and by the "-w" option in
the Unix "sz" program.  In this mode, the sender assumes that there is a
"window" of buffer space in the receiving program which it is not
allowed to over-fill.  The sender transmits four packets, each of which
contains (windowsize/4) bytes of data;  attached to each packet is a
code which means "Please acknowledge this when you get it."  The
receiver sends back an acknowledgement as soon as it has decoded a
packet and written it to disk... this "opens the window" for the sender
to transmit another packet.  In almost all cases, the receiver will have
sent back the acknowledgement for packet #1 before the sender has
finished transmitting packet #4, and thus the transmitter can go ahead
and send #5 immediately.  If the receiver gets bogged down for any
reason, the sender will not receive ACKs promptly, and will simply wait
for the ACKs before it sends any more data.

With this scheme, there are never more than "windowsize" bytes of data
"in transit" at any one time.

I almost always use sliding-window mode with ZMODEM.  It adds only a
very slight amount of overhead, and its end-to-end flow control makes
uploading and downloading more reliable.

>	3: How can I optimize the transfer speed *to* the VAX without 
>	   affecting the transfer speed *from* the VAX?

The packet-size and window-limit parameters are set at the transmitting
end, not at the receiving end.  So, if you tweak them in ZTerm's
configuration, they'll affect uploads to the VAX, but will not affect
downloads from the VAX.  You can use equivalent options to "sz" if you
want to add sliding-window mode to your downloads.

>Thanks a lot in advance!

You're welcome!
-- 
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