When every we get a new highspeed modem we always run a
series of file transfer tests using a group of protocols to
see how they fair with the new modem.

Protocols Tested:

Tmodem v 6.10 (Micro TECH Systems, Inc.)
Zmax v 1.00b (Micro TECH Systems, Inc.)
Zmodem
Xmodem-1K
Ymodem Batch
Ymodem with OverThrust
Ymodem-G
MPT v1.10 (Matthew Thomas)
Jmodem v38 (Unknown)
BiModem v1.24 (Erik Lab)

Protocol Characteristics:

Tmodem v6.10 : Batch Protocol, Error Recovery, Restart
Aborted Transfers (Registered version), 32 Bit CRC at low
speeds and proprietary Error Correction similar to 64 bit CRC
at highspeeds.

Zmax v1.00b : Batch Protocol, Error Recovery, Restart
Aborted Transfers, and 32 Bit CRCs.

Zmodem : Batch Protocol, Error Recovery, Restart
Aborted Transfers, 16 bit CRCs and 32 bit CRCs.

Xmodem1K : Non-Batch, Error Recovery, and 16 Bit CRC

Ymodem Batch : Batch Protocol, Error Recovery, 16 Bit CRCs

Ymodem Batch with Overthrust/Overdrive : Batch Protocol, No
Error Recovery, 16 Bit CRCs.

Ymodem-G : Batch Protocol, No Error Recovery, 16 Bit CRCs.

MPT 1.10 : Batch Protocol, Error Recovery, Assumed 16 BIT
CRCs, Restart Aborted Transfers.

Jmodem : Non-Batch Protocol, Error Recovery, 16 BIT CRC.

Bimodem : Batch Protocol, Error Recovery, Restart Aborted
Transfers, 16 BIT CRCs (assumed). Bimodem can transfer and
receive at the same time, but because this is a highspeed
modem and like many, not all, but many highspeed modems, it
is half duplix and bimodem can only function as a single
direction protocol.


Test File : 124,991 byte compressed LHARC (LZH) file.

Test Computers: Two 6 Mhz AT's with Mono Graphic screens and
40 Mls Harddrives. One computer running Osiris SE Multi-Line
BBS and the other computer running QT 2000.

NOTE: Slower computers were used to bring out the protocols
CPU overhead. Any protocol can drive a highspeed modem if
it's running on a 33 Mzh 386 or 486....but put it on a slower
computer....

Test Modems : Two Speedmodems with latest ROM locked at
19,200.

Transfers were all done on the same call so the same line
quality would be present for all transfers.

Results in order from highest to lowest:

Rank Protocol Efficiency CPS

1 Tmodem 96% 921.6
2 Zmax 94% 902.4
3 Ymodem-G 94% 902.4
4 Zmodem 90% 864
5 Ymodem OD/OT 87% 835.2
6 Bimodem 79% 758.4
7 MPT 1.10 78% 748.8
8 Jmodem 54% 518.4
9 Ymodem Batch 40% 384
10 Xmodem1K 40% 384

Not bad CPS ratings for a 169 dollar Modem/Fax/Voice Mail
Card.

With *H2, errors aren't possible between the two modems.
Strictly speaking, they are but the modems take care of it
and you never see it on your end (protocol driver).

The place errors occur is between the modem and the protocol
driver.

This tests the protocols timing sensitivity, data testing
reliability, and the protocols ability to keep up with the
incoming data stream.

Two protocols reported errors:

MPT 1.10 always (during 5 test downloads) reported an error

on the first block. Error recovery speed was good.

Bimodem 1.24 reported errors during 2 of the 5 test
downloads. The error recovery was very slow.

In all fairness to Bimodem, it did test out to be fast at
2400 baud during bi-directional transfers, providing the
lines were very clean (not likely under real life conditions)
and no errors were likely.

When line noise WAS encountered, it aborted 2 of the 6
transfers and the ones that did not abort dropped to below
130 cps, not good at all.

MPT 1.10 seems to work good at 2400 baud, about Zmodem speed.

The results of the tests were not surprising and pretty much
as expected.

Tmodem was clearly the winner followed closely by our other
protocol, Zmax.

One thing I would like to point out, Bimodem's doc's show a
comparison against Zmodem and they claim it is faster. What
they fail to tell you; the tests are rigged in favor of
Bimodem. I'm no fan of Zmodem, but I like rigged tests even
LESS, we get enough of that from magazines.

As you can plainly see, even old reliable Ymodem Batch with
Overthrust walks all over Bimodem in real life.....do you
really want to spend 25.00 for a protocol that YMODEM CAN
BEAT?

Bare in mind that one of these days you will want to move to
a highspeed modem (if you don't already have one) and v.32
(full duplex) may be a "STANDARD" on paper, but it sure isn't
in the REAL world, and never will be. That is if US Robotics
(keeping in mind that when two USR's connect, they do so in
half duplex mode), CompuCom, and several other major players
have anything to say about it and they will.