Tom Jennings
11 Oct 88

This is how the Zmodem implementation in Fido/FidoNet 12i and
FidoTerm version 2 works. 

This is a fully compatible, standard Zmodem implementation, with
a few fancy features added. You can, and probably should adjust
Zmodems behaviour with the two controls in FIDO.INI (details
follow), because Zmodem can potentially accept data faster than
your computer can handle. The default settings are quite
conservative, and should work on all machines. 


Zmodem Features

This Zmodem implementation has the following basic
characteristics: (Skip this if you don't care)

Block sizes:	1024 bytes 	above 2400 baud
		 512		2400 baud
		 256		1200 baud and below

Upon four consecutive errors on the same block, the block size is
halved; minimum block size is 64 bytes.

Upon forty consecutive blocks with no errors and no line noise
junk characters, block size is doubled; maximum block size is
1024 bytes.


Zmodem Controls

Zmodem Receive controls allow either full streaming, or fully
acknowledged blocks.

Zmodem Transmit controls allow full streaming, or a sliding
window, the window size stated in either Kbytes or number of
blocks.


Zmodem Installation

PLEASE: You have to very thoroughly TEST, TEST, TEST after you
change Zmodem settings, particularly if you enable full
streaming. Especially at 9600 baud and above, wrong settings can
make the difference between breathtaking 1100 byte per second
transfers, and performance worse than the slowest XMODEM. Make
sure your computer can actually handle what you tell Zmodem to
do.

Keep in mind the whole point of having high speed modems and
protocols was so that you can run as fast as your machine allows;
a modem capable of 1500 characters per second doesn't make your
computer any faster, all it guarentees is that it won't hold you
back.

Computers and Modems

I don't have enough experience with Zmodem at this point to make
hard reccomendations. Zmodem performance is limited by the modem
and computer (processor and disks) combination you have, plus
other factors like multitaskers and LANs. I'll just list some
anecdotal stuff:

If you have a very fast modem (US Robotics HST, Telebit
Trailblazer, Hayes V-series, etc) and an ordinary pclone low or
medium performance computer, you will have to be very careful
with your installation; it is extremely easy to make Zmodem
accept data faster than your computer can write it to disk! 

If you have a 300/1200 modem, use full streaming for receive, and
a sliding window of 4 to 8 blocks; start with 6. At 1200 baud,
you'd be hard pressed to have Zmodem deliver data to your
computer faster than it could write it to disk. 

If you have funny background software like LANs, multitaskers
like DoubleDOS, DESQview, TOPView, etc, certain popup utilities,
funny device drivers, you may find that they slow your computer
down, when they are active, and make full streaming fail
miserably.

High performance machines like fast 286's or 386 boxes can
probably run full streaming, probably even with multitaskers.

If you've got a "turbo" pclone with the usual slow as molasses
disk drive, and a fast modem, you can probably make full
streaming work if you don't have any funny software running. 

For example, the Fido Software BBS is a cheap "turbo" pclone
running at 8MHz, with an 80 mS disk drive, and a US Robotics HST
locked at 9600 baud (modem type 16). This seems to work just
fine, it accepts uploads from a PS/2 and HST locked at 19,200
baud at full speed without a hitch.

But, with Fido set for modem-type 17 (locked at 19,200) instead
of modem-type 16 (locked at 9600) it fails miserably. Take this
as a hint as to what you're getting into.

HINT: Always use a sliding window, even if it's huge, and huge is
not better than small. Start with a tiny window, make it slightly
larger, and when an increase in window size doesn't affect
performance, use the next size smaller.

All that a large window size will do for you is make for TERRIBLE
ERROR RECOVERY!!! Don't overdo it!

HINT: Don't look at the Senders modem activity lights when
adjusting window size; look only at the Receivers lights. The
senders activity can be misleading; for example, the US Robotics
HST has a 32K byte internal buffer, so Zmodem fills it quickly
then sits and waits for window synchronization; don't let this
fool you into thinking you could make it faster, you can't. Data
can only flow out of the modem into the phone line as fast as it
goes, all that increasing the window size will do is make error
recovery slower, and will slow down the transfer incredibly.


Modem Installation

Zmodem makes modem installation critical if you have a "9600
baud" modem. Most of these modems use a "locked baud rate"
between the modem and computer; what this means is that
regardless of the speed that your BBS modem connects to a caller
or other BBS, the computer and modem communicate at a fixed baud
rate, usually 9600 or 19,200 baud. This is done for performance
reasons, plus the related fact that "9600 baud" modems don't work
exactly the same as 2400 and below modems, and there is this
"hardware handshake" junk that goes on between the modem and
computer so that they can avoid losing data due to the high data
rate.

9600 baud is quick stuff; about 960 characters a second, and at
one interrupt per character the poor processor is hard pressed to
keep up with the data flow. Slow machines lose data and get lots
of errors; fast ones make it.

If you've got a machine less than 8MHz, especially if it's an
8088, use the variable rate modem type or locked at 9600. Locked
at 19,200 worked OK with Xmodem, because the blocks were so
small, just as the computer was about to lose it the data stopped
coming in and it caught up; with Zmodem it won't get the chance.


Zmodem Controls

The receive controls affect only how your Fido/FidoNet or FT
program receives files; if someone else calls in to download
files, Zmodem will go as fast as their Zmodem tells Fido or FT to
go. (They may have done something like this on their end as
well.)

---------------- RECEIVE: FULL STREAMING ----------------

FT:		0/D
Fido: 		zm-rx-type 0

When receiving file(s), tells the sending program that it can
accept data at maximum possible data rate, ie. full streaming.
This is meant for reasonably high performance machines that can
accept data at "high speed", whatever that means to you. It will
probably get lots of errors if you have a multitasker running, or
have really noisy phone lines, or a slow machine, etc. 


---------------- RECEIVE: FULLY ACK'ED ----------------

FT:		1/D
Fido:		zm-rx-type 1

When receiving files, every block will be acknowledged. For
sending, Fido/FT will do whatever the receiver says, of course.
If for instance your 4.77MHz pclone with an 80 mS drive Fido is
running under DoubleDOS, and a caller calls in with a 20MHz 386,
and downloads a file to a RAMdisk, Fido will only send the data
as fast as it possibly can; if that same hardware hog were to
upload however, Fido would still insist on ACKing every block.

Note that regardless of the senders hardware, you would be hard
pressed to overrun even a lowly 4.77MHz Fido at 2400 baud or
below. (Well, maybe at 2400 ... you'll have to try it.) No
processor in the world can push more data through a slow modem.



------------ TRANSMIT: VARIABLE SLIDING WINDOW ------------

FT:		<blocks>/U		1 - 64
Fido:		zm-tx-type <blocks>	1 - 64

This is the preferred method of defining a sliding window. When
sending files, and the receiver says it can accept full streaming
Fido/FT will send data in full streaming mode, as long as it
receives acknowledges from the receiver every so many <blocks>.
The receiver sends occasional acknowledges, and the sender checks
for them, without pausing the data flow. If the sender doesn't
see an acknowledge it will stop and wait for one.

In most cases, this has all the speed of full streaming, with
much improved error recovery. The slight penalty is the reverse
channel does get used, which could slow some > 2400 modems down.
Certainly at 2400 and under there seems to be no penalty at all.
This will be the default mode for Fido and FT, I think.

Since the window size is stated in blocks, the size of the window
depends on the baud rate and error rate; if many errors occur,
Zmodem shrinks the block size, and hence the window shrinks too;
if the error rate is exceptionally good, the block size increases
as Zmodem increases block size. Higher baud rates start with
larger blocks.

Window size is:

	window size = <blocks> * block size


I'd recommend starting with <blocks> at 6, which works out to be
a 1.5K byte window at 300 and 1200 baud, 3K at 2400, and 6K at
9600 and beyond.

HINT: Don't look at the Senders modem activity lights when
adjusting window size; look only at the Receivers lights. The
senders activity can be misleading; for example, the US Robotics
HST has a 32K byte internal buffer, so Zmodem fills it quickly
then sits and waits for window synchronization; don't let this
fool you into thinking you could make it faster, you can't. Data
can only flow out of the modem into the phone line as fast as it
goes, all that increasing the window size will do is make error
recovery slower, and will slow down the transfer incredibly.


------------ TRANSMIT: FIXED SIZE SLIDING WINDOW ------------

FT:		<windowsize>/U
Fido:		zm-tx-type <windowsize> 1024 - 65536

This is the second method of defining a sliding window. It works
the same as the previous method, except the size of the window is
fixed, and specified in Kbytes. An 8K window is an 8K window,
whether it contains 8 1024 byte blocks or 32 256 byte blocks.

The variable size sliding window is probably more flexible, in
that if the block size decreases due to line noise or whatever,
the window size decreases too.

