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<6C>
|
|||
|
|
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.
|
|||
|
|
|