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.