246 lines
9.7 KiB
Plaintext
246 lines
9.7 KiB
Plaintext
Tom Jennings
|
||
11 Oct 88
|
||
|
||
This is how the Zmodem implementation in Fido/FidoNet 12i and<6E>
|
||
FidoTerm version 2 works.
|
||
|
||
This is a fully compatible, standard Zmodem implementation, with<74>
|
||
a few fancy features added. You can, and probably should adjust<73>
|
||
Zmodems behaviour with the two controls in FIDO.INI (details<6C>
|
||
follow), because Zmodem can potentially accept data faster than<61>
|
||
your computer can handle. The default settings are quite<74>
|
||
conservative, and should work on all machines.
|
||
|
||
|
||
Zmodem Features
|
||
|
||
This Zmodem implementation has the following basic<69>
|
||
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<69>
|
||
halved; minimum block size is 64 bytes.
|
||
|
||
Upon forty consecutive blocks with no errors and no line noise<73>
|
||
junk characters, block size is doubled; maximum block size is<69>
|
||
1024 bytes.
|
||
|
||
|
||
Zmodem Controls
|
||
|
||
Zmodem Receive controls allow either full streaming, or fully<6C>
|
||
acknowledged blocks.
|
||
|
||
Zmodem Transmit controls allow full streaming, or a sliding<6E>
|
||
window, the window size stated in either Kbytes or number of<6F>
|
||
blocks.
|
||
|
||
|
||
Zmodem Installation
|
||
|
||
PLEASE: You have to very thoroughly TEST, TEST, TEST after you<6F>
|
||
change Zmodem settings, particularly if you enable full
|
||
streaming. Especially at 9600 baud and above, wrong settings can<61>
|
||
make the difference between breathtaking 1100 byte per second<6E>
|
||
transfers, and performance worse than the slowest XMODEM. Make<6B>
|
||
sure your computer can actually handle what you tell Zmodem to<74>
|
||
do.
|
||
|
||
Keep in mind the whole point of having high speed modems and<6E>
|
||
protocols was so that you can run as fast as your machine allows;<3B>
|
||
a modem capable of 1500 characters per second doesn't make your<75>
|
||
computer any faster, all it guarentees is that it won't hold you<6F>
|
||
back.
|
||
|
||
Computers and Modems
|
||
|
||
I don't have enough experience with Zmodem at this point to make<6B>
|
||
hard reccomendations. Zmodem performance is limited by the modem<65>
|
||
and computer (processor and disks) combination you have, plus<75>
|
||
other factors like multitaskers and LANs. I'll just list some<6D>
|
||
anecdotal stuff:
|
||
|
||
If you have a very fast modem (US Robotics HST, Telebit<69>
|
||
Trailblazer, Hayes V-series, etc) and an ordinary pclone low or<6F>
|
||
medium performance computer, you will have to be very careful<75>
|
||
with your installation; it is extremely easy to make Zmodem<65>
|
||
accept data faster than your computer can write it to disk!
|
||
|
||
If you have a 300/1200 modem, use full streaming for receive, and<6E>
|
||
a sliding window of 4 to 8 blocks; start with 6. At 1200 baud,<2C>
|
||
you'd be hard pressed to have Zmodem deliver data to your<75>
|
||
computer faster than it could write it to disk.
|
||
|
||
If you have funny background software like LANs, multitaskers<72>
|
||
like DoubleDOS, DESQview, TOPView, etc, certain popup utilities,<2C>
|
||
funny device drivers, you may find that they slow your computer<65>
|
||
down, when they are active, and make full streaming fail<69>
|
||
miserably.
|
||
|
||
High performance machines like fast 286's or 386 boxes can<61>
|
||
probably run full streaming, probably even with multitaskers.
|
||
|
||
If you've got a "turbo" pclone with the usual slow as molasses<65>
|
||
disk drive, and a fast modem, you can probably make full<6C>
|
||
streaming work if you don't have any funny software running.
|
||
|
||
For example, the Fido Software BBS is a cheap "turbo" pclone<6E>
|
||
running at 8MHz, with an 80 mS disk drive, and a US Robotics HST<53>
|
||
locked at 9600 baud (modem type 16). This seems to work just<73>
|
||
fine, it accepts uploads from a PS/2 and HST locked at 19,200<30>
|
||
baud at full speed without a hitch.
|
||
|
||
But, with Fido set for modem-type 17 (locked at 19,200) instead<61>
|
||
of modem-type 16 (locked at 9600) it fails miserably. Take this<69>
|
||
as a hint as to what you're getting into.
|
||
|
||
HINT: Always use a sliding window, even if it's huge, and huge is<69>
|
||
not better than small. Start with a tiny window, make it slightly<6C>
|
||
larger, and when an increase in window size doesn't affect<63>
|
||
performance, use the next size smaller.
|
||
|
||
All that a large window size will do for you is make for TERRIBLE<4C>
|
||
ERROR RECOVERY!!! Don't overdo it!
|
||
|
||
HINT: Don't look at the Senders modem activity lights when<65>
|
||
adjusting window size; look only at the Receivers lights. The<68>
|
||
senders activity can be misleading; for example, the US Robotics<63>
|
||
HST has a 32K byte internal buffer, so Zmodem fills it quickly<6C>
|
||
then sits and waits for window synchronization; don't let this<69>
|
||
fool you into thinking you could make it faster, you can't. Data<74>
|
||
can only flow out of the modem into the phone line as fast as it<69>
|
||
goes, all that increasing the window size will do is make error<6F>
|
||
recovery slower, and will slow down the transfer incredibly.
|
||
|
||
|
||
Modem Installation
|
||
|
||
Zmodem makes modem installation critical if you have a "9600<30>
|
||
baud" modem. Most of these modems use a "locked baud rate"<22>
|
||
between the modem and computer; what this means is that<61>
|
||
regardless of the speed that your BBS modem connects to a caller<65>
|
||
or other BBS, the computer and modem communicate at a fixed baud<75>
|
||
rate, usually 9600 or 19,200 baud. This is done for performance<63>
|
||
reasons, plus the related fact that "9600 baud" modems don't work<72>
|
||
exactly the same as 2400 and below modems, and there is this<69>
|
||
"hardware handshake" junk that goes on between the modem and<6E>
|
||
computer so that they can avoid losing data due to the high data<74>
|
||
rate.
|
||
|
||
9600 baud is quick stuff; about 960 characters a second, and at<61>
|
||
one interrupt per character the poor processor is hard pressed to<74>
|
||
keep up with the data flow. Slow machines lose data and get lots<74>
|
||
of errors; fast ones make it.
|
||
|
||
If you've got a machine less than 8MHz, especially if it's an<61>
|
||
8088, use the variable rate modem type or locked at 9600. Locked<65>
|
||
at 19,200 worked OK with Xmodem, because the blocks were so<73>
|
||
small, just as the computer was about to lose it the data stopped<65>
|
||
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<46>
|
||
program receives files; if someone else calls in to download<61>
|
||
files, Zmodem will go as fast as their Zmodem tells Fido or FT to<74>
|
||
go. (They may have done something like this on their end as<61>
|
||
well.)
|
||
|
||
---------------- RECEIVE: FULL STREAMING ----------------
|
||
|
||
FT: 0/D
|
||
Fido: zm-rx-type 0
|
||
|
||
When receiving file(s), tells the sending program that it can<61>
|
||
accept data at maximum possible data rate, ie. full streaming.<2E>
|
||
This is meant for reasonably high performance machines that can<61>
|
||
accept data at "high speed", whatever that means to you. It will<6C>
|
||
probably get lots of errors if you have a multitasker running, or<6F>
|
||
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<6F>
|
||
sending, Fido/FT will do whatever the receiver says, of course.<2E>
|
||
If for instance your 4.77MHz pclone with an 80 mS drive Fido is<69>
|
||
running under DoubleDOS, and a caller calls in with a 20MHz 386,<2C>
|
||
and downloads a file to a RAMdisk, Fido will only send the data<74>
|
||
as fast as it possibly can; if that same hardware hog were to<74>
|
||
upload however, Fido would still insist on ACKing every block.
|
||
|
||
Note that regardless of the senders hardware, you would be hard<72>
|
||
pressed to overrun even a lowly 4.77MHz Fido at 2400 baud or<6F>
|
||
below. (Well, maybe at 2400 ... you'll have to try it.) No<4E>
|
||
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<65>
|
||
sending files, and the receiver says it can accept full streaming<6E>
|
||
Fido/FT will send data in full streaming mode, as long as it<69>
|
||
receives acknowledges from the receiver every so many <blocks>.<2E>
|
||
The receiver sends occasional acknowledges, and the sender checks<6B>
|
||
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<74>
|
||
much improved error recovery. The slight penalty is the reverse<73>
|
||
channel does get used, which could slow some > 2400 modems down.<2E>
|
||
Certainly at 2400 and under there seems to be no penalty at all.<2E>
|
||
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<6F>
|
||
depends on the baud rate and error rate; if many errors occur,<2C>
|
||
Zmodem shrinks the block size, and hence the window shrinks too;<3B>
|
||
if the error rate is exceptionally good, the block size increases<65>
|
||
as Zmodem increases block size. Higher baud rates start with<74>
|
||
larger blocks.
|
||
|
||
Window size is:
|
||
|
||
window size = <blocks> * block size
|
||
|
||
|
||
I'd recommend starting with <blocks> at 6, which works out to be<62>
|
||
a 1.5K byte window at 300 and 1200 baud, 3K at 2400, and 6K at<61>
|
||
9600 and beyond.
|
||
|
||
HINT: Don't look at the Senders modem activity lights when<65>
|
||
adjusting window size; look only at the Receivers lights. The<68>
|
||
senders activity can be misleading; for example, the US Robotics<63>
|
||
HST has a 32K byte internal buffer, so Zmodem fills it quickly<6C>
|
||
then sits and waits for window synchronization; don't let this<69>
|
||
fool you into thinking you could make it faster, you can't. Data<74>
|
||
can only flow out of the modem into the phone line as fast as it<69>
|
||
goes, all that increasing the window size will do is make error<6F>
|
||
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<6B>
|
||
the same as the previous method, except the size of the window is<69>
|
||
fixed, and specified in Kbytes. An 8K window is an 8K window,<2C>
|
||
whether it contains 8 1024 byte blocks or 32 256 byte blocks.
|
||
|
||
The variable size sliding window is probably more flexible, in<69>
|
||
that if the block size decreases due to line noise or whatever,<2C>
|
||
the window size decreases too.
|
||
|