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: /U 1 - 64 Fido: zm-tx-type 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 .¨ 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 = * block size I'd recommend starting with 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: /U Fido: zm-tx-type 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.