NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/archives/msdos/d/110

Internet Message Format | 1992-12-22 | 16.6 KB

Xref: sparky comp.archives.msdos.d:110 comp.binaries.ibm.pc.archives:5213 comp.dcom.modems:18410
Newsgroups: comp.archives.msdos.d,comp.binaries.ibm.pc.archives,comp.dcom.modems
Path: sparky!uunet!walter!porthos!navaho.cc.bellcore.com!dml7
From: [e-mail] (lee,danny)
Subject: *** WHAT'S THE BEST COMM PROTOCOL {LONG SUMMARY} ***
Organization: Bellcore, Livingston, NJ
Date: Tue, 22 Dec 92 20:38:02 GMT
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET System Software)
Lines: 353

_________________ABSTRACT_________________

Subject: *** WHAT'S THE BEST COMM PROTOCOL ***

here's a summary of the replies/forwards i've received.  thanks to
all for your help.  seems like the _OLD_ versions of kermit are very
slow.  the newest version is 3.12.  this version is comparable to
zmodem, though zmodem is still faster i gather.  kermit however is
more readily available and accessible in various operating systems,
whereas with zmodem, one would have to port the appropriate sz and
rz code over.  zmodem has the ability to continue a file transfer
at a point where it was broken off previously.  don't know whether
the newest version of kermit has this ability.  zmodem also uses
a crc-32 bit error checking, which is more reliable than what
kermit uses (checksums).  i do not know whether kermit's new version
uses something different.  refer below for more info.  note that
comments/questions by me will be preceded by a ">>>>>>>".  have a safe
and merry one!  should there be more interest on this discussion, please
continue it on the newsgroup.  not all responses were included, since
many were redundant, and some responses may be cut short.  thanks once
again.

dan

_________________QUESTION_________________

i'm having trouble deciding which communications protocol package to
use on my pc.  i was using kermit and still using it.  however,
someone mentioned to me that zmodem was much better and faster.
one can assume that speed and reliability are the main factors
to consider.  which one (kermit or zmodem, or any other ones)
would permit one to download/upload most efficiently and most
quickly?  obviously, modem speed plays a role as well.  please
e-mail me below or post.  i will summarize should there be enough
interest.  thanks in advance.

_________________ANSWERS_________________

I find that ms-kermit 3.11 or 3.12 transfers data at over 80% of 2400
baud (my modem speed)--I doubt if significant improvement is possible.
No experience at 9600.  386sx with MS-DOS 5, local phone connection of
average quality (a few percent retries).  Transferring data from a
MicroVax II with c-kermit 5A.  Block size about 940 bytes, 2 sliding
windows.

_______

most comm programs now should automatically support zmodem as well as
ymodem and xmodem, internally.  that is they have it as part of the
program.  if you don't have it you could get dsz1209.zip which does the

>>>>>>> i've checked oakland, a mirror site for simtel.  seems like
        dsz1109.zip and gsz1109.zip are the newest versions.  correct me
        if i'm mistaken.

above mentioned.  you call it from within the comm program.
zmodem is the fastest, much more so than kermit.  but if you really want a
good comm protocol, i suggest hslink or bimodem.  with this you can

>>>>>>> any confirmation on this?  hslink and bimodem being faster
        than zmodem.  these types of programs would prove most useful
        for file transfers between 2 dos machines, since i would
        imagine not too many other operating systems would support them.

download and upload at the same time!  the speed is about the same as
zmodem.  but with zmodem could can only do upload OR download, but not
both at the same time.  hslink is very easy to install.  i have problems
with bimodem.

the best solution is to put out $250 and get a 14.4k modem.  then
everything will be fast enough that you really don't care if it's kermit
or zmodem...

_______

    Sorry I didn't explain the difference very well.  The new version of
kermit that someone was referring to was most likely long block kermit.
It is fast in that the packets it sends are larger so it does not have
to send and then wait for a response 60 times a minute, only 10 for example.
Zmodem uses Cyclic Redundancy Checking modulo 32 (CRC-32) which is nothing
more than an error control protocol.  It it able to send a great deal of
data very quickly and check for errors and recover from errors at the same
time.  Kermit on the other hand is VERY slow as it was one of, if not THE,
first protocol.  It is great for moving data between generally incompatible
machines like a UNIX box and a DOS machine or a UNIX box and an IBM mainframe.
Kermit is implemented on most everything where zmodem is quite new and is
not yet supported everywhere.  There are tons of protocols out there like
Y-modem, y-modem-1k, kermit, compuserve B+, x-modem, z-modem and countless
others.  Again, as I said, I love zmodem and only use that.  I just ported
the code onto our NeXT machines and Sun Sparc stations so I can download/upload
to my DOS machine at home.  It's nice when something goes wrong during a
download and you can pick up from that exact point instead of having to
start the complete download over again.  Hope this helps.

_______

Slowest <--------------------> Fastest
kermit    xmodem    ymodem    zmodem

For the MS-DOS world, Procomm+ has good terminal emulation
and file transfer protocols.

>>>>>>> i use procomm + for windows.  would anyone know what versions
        of kermit and x/y/z/modem it is using?  it wouldn't be too hard to
        configure it to use newer versions that i download, would it?
        does anyone have a favorite communications package they use?
        i heard telix is pretty good, but haven't tried it myself.

FIle transfer speed is affected by modem configuration, too,
unless one is using a non-MNP or V.42bis modem.

_______

A sliding window speeds up transmission in the presence of retries.  Up to
4 may be used on very noisy lines.  The more windows, the smaller the block
size, which also makes sense on noisy lines.  If retries are very infrequent,
do not use any (set windows 1, not 0).  I don't understand the exact details.

_______

I prefer KERMIT.  Most people who complain about KERMIT being slow,
have not used the newer versions.  ZMODEM is faster than old kermit
because it has 2048 buffers and sliding windows.  The latest and
greatest Kermit also can handle big buffers and sliding windows.  I think
ZMODEM is slightly more effiencent (a byte or two less overhead) but that
is overshadowed by KERMIT's popularity and versitility.

Most comercial packages that support "kermit" do not support these features
while versions from columbia do.

I use KERMIT (with BB and sliding windows) to/from the VAX at work and
routinly get over 900cps sending compressed data over a 9600bps circuit.
I use ZMODEM when talking to BBSs becuase they don't have any advanced
Kermit and they are used to ZMODEM and get the same results.

In your summary you may want to differentiate the older versions of kermit
from the newer ones.  If people don't know the difference they probably
mean the older one.

_______

For file transfer I use zmodem, it is faster and more reliable.

Kermit
 Has the advantage of working on old equipment that can't handle a
 streaming protocol.  The university had some old equipment that would
 noticably slow down if 4 or so people tried to use zmodem.

 Disadvantage error detection is a checksum.  Will not get a correct
 file on a real noisy phone line.

 Effective transfer rate is about half the bit rate on the line.  2400
 bps modem will transfer at about 1200 bps (120 char/sec).

zmodem
 Uses a crc for error detection.  It will detect more errors, but I
 don't think it runs at all on a real noisy line.

 Has data compression that can be used.  At 2400 bps transfer rate is
 about 200 char/sec; on same file with compression I get 440
 char/sec.  With zmodem transfer rates vary with the file being
 transfered, and how mush compression varies widely.

_______

The answer is rather unambiguously zmodem.  If one speaks of the
different telecommunications packages, there are many of them in
use, and the opinnions can be quite divided.  But as for file
transfers zmodem seems to dominate in actual usage.  I am not being
partisan, but rather observing the current practice.

If one goes down to details, all transfer protocols have their
proponents, and if you can lay your hands on kermit with long
packages, it is fair, too.  But it has one drawback which I don't
like at all.  That is that it does not preserve the file's date
stamp in the transfer.

_______

In my limited experience, Zmodem beats Kermit easily.  The implementations
of Kermit that I've used (VAX/VMS and IBM/CMS) are both far too slow
(barely faster than XMODEM), running in the 7 to 9K per minute range w/ my
2400 bps modem (very approximate times; I haven't used it in a while...).
Zmodem (using DSZ or GSZ from Omen Technologies on the PC end and SZ [also
Omen] on our VAX - both available from SIMTEL20, etc.) generally gives
slightly over 13K per minute, along with better error correction, crashed
transfer recovery (if a large file xfer crashes in midstream, you can pick
up where it left off instead of restarting from the first byte), and a very
nice graphical (sort of) interface if you use GSZ instead of DSZ.

Possible disadvantages: finding Zmodem for whatever system you're
transferring FROM (I presume there's a UNIX implementation?) if it's not
another PC, and, of course, paying the fee.  DSZ and GSZ are shareware;
MS-Kermit is free (as, presumably, is the Kermit that's built into whatever
other comm program you might be using now).  The VAX/VMS version of SZ,
incidentally, refuses to communicate with non-Omen Zmodem programs.
Between 2 PCs, though, I presume you could use a FREE Zmodem
implementation, one or two of which are also at SIMTEL.

_______

I'll probably go check out the kermit newsgroup after I post this, but
I think it might be relevant here too.

Has anyone heard of/used a new addition called SuperBlock Kermit?  I believe
it was originally developed for use with the unix clone Coherent, and has
since been ported to the NeXT platform as well.

Now, I'm not sure on the details, but supposedly it's a streaming protocol
like zmodem.  Zmodem (and I may be wrong here, so feel free to correct me),
when it determines that it's received a bad block (via CRC checks?), it
signals the sender to restart at block such-and-such, and start over from
there.  Evidently the new kermit, instead of resending everything from
that block on, justs asks for that specific block.  So, if you do have
and err, it tries to just fix that one block rather than starting over.
As a result, it's supposed to get better transfer rate than zmodem.  Of
course, I still don't know anything about crash recovery (that is,
picking up from where you left off after an aborted transfer, zmodem
may still be better for that).

Does anyone know if this is true, and if so, where I can get binaries for
DOS and source for unix?

Like I said, this may be better asked in the kermit group, but it might
be of interest to people here as well.

_______

Let's get very specific about what you need to do to make Kermit run at near
Zmodem speeds. Here are the settings I use:

set send packet 2000
set rec packet 2000
set window 2

 ..no claim that this is optimimum for your (or any situation) but it does
speed up kermit something fierce for me; especially at higher serial speeds.

 Zmodem is essentially Xmodem with bigger packets and sliding
windows (plus a few nice extra enhancements) which is about what these commands
do to any reasonably recent and complete Kermit. Kermits usually are set
up to use the ancient settings by default for backwards compatability,
which makes it look a lot worse than it is if you don't take the time
to experiment a bit.

_______

    Older versions of Kermit were very slow in file transfers.
The newer versions (>3.1) are much better.  In my tests, it runs
at least 90% of the zmodem speed.  However, for text files, the
zmodem compress option (-B) gives zmodem a clear advantage.
    However, zmodem is much more vulnerable to line noise.
Our lines are often noisy; zmodem gets what it thinks is an
abort signal and drops the line.  Kermit's quit-and-go-home
signal is longer, or something, as it almost never gets fooled
by line noise.
    I often collect several files and then start the download
(~0400) just before I go to bed.  This is rarely successful with
zmodem, while kermit almost always succeeds.
    On the other hand, zmodem has a restart capability that
will complete a partial file.
    So, for short, esp ascii files, use zmodem.  For long
unattended transfers, use Kermit.

_______

While xmodem and zmodem might provide some percentage gains (sometimes
small, somtimes rather large[in the range of 30% or so]) in file transfer
rate, it is all meaningless if they just won't work for you.

Kermit always uses a standard set of ASCII characters for transmitting
the data (even in binary format?) that is immune to the problems that
arise using the other transfer formats when the data being transferred
is a XON, XOFF or any of a number of other control characters used in
text flow/format control.  This makes kermit the format of choice for
users who have there system connected to a data network via a terminal
server or 4-line rs-232 connection that does not have hardware flow
control, thus requiring XON/XOFF flow control.

I have looked at the man page and help output for xmodem, and do not
see any way of altering it to avoid the XON/XOFF problem.  If it's
there, I'm sure we'll hear about it.

It's kind of like the archiver controversy;
  each may have some aspect that is better than the others,
  and you have to use the appropriate one for the target of your operation,
  so you need to keep them all around to use when the need arises.

>>>>>>> very good point.

>I have looked at the man page and help output for xmodem, and do not
>see any way of altering it to avoid the XON/XOFF problem.  If it's
>there, I'm sure we'll hear about it.

I am using ZMODEM through a network controller which uses ascii 30 to
do an escape to command-mode.  Therefore I use the sz/rz -e option,
which basically avoids using codes less than 32 -- this also avoids the
XON/XOFF problem (I believe).

As it converts these characters to two character sequences, the transfer
get longer -- but works without a hitch.

Please note that this ONLY applies to rz/sz programs which implements
this particular feature of ZMODEM.  I believe ZMODEM to be the most
simple protocol to implement; kermit may be smarter but still _very_
difficult to get right when having routines in your own programs.

_______

 If you get a copy of Kermit which is less than a few years old
 and which does both long packets and sliding windows, then the
 file transfer efficiency matches that of Zmodem within a
 percentage point or so (by actual tests done by others and
 myself).

    If you get one which is fairly recent and which also supports
 the SET FILE TYPE LABELED option, then it will preserve all file
 attributes during transfers.  This is dependant upon what the
 operating system supports and having a recent version of Kermit.

    I find Kermit is better for text transfers between dissimilar
 operating systems, as it converts file types.  It's also better
 for multiple transfer operations as you can put one of the
 Kermits into server mode.

    If you are working to a system which does not have Kermit
 which supports long packes, then Zmodem will have better file
 transfer efficiency.

_______

>Let's get very specific about what you need to do to make Kermit run at near
>Zmodem speeds. Here are the settings I use:
>set send packet 2000
>set rec packet 2000
>set window 2

>up to use the ancient settings by default for backwards compatability,
>which makes it look a lot worse than it is if you don't take the time
>to experiment a bit.

Time which I took long ago, before switching to Zmodem.  Our local VAX has
an older Kermit (VMS Kermit-32 version 3.3.126), which only supports packet
lengths up to 1000 and doesn't do sliding windows (as far as I could find,
anyway).  It was far easier to grab the VMS Zmodem from SIMTEL20 and start
using that than it would have been to convince our system administrators to
upgrade Kermit.  And given Zmodem's crash recovery, strong error checking /
correction (it's never given me an unrecoverable error due to anything but
one machine or the other going down...), and nifty  graphical display
(courtesy GSZ), I doubt that I'd go back even if they did upgrade.

However, the bottom line seems to be that the BEST protocol for any
situation depends more on the situation than it does on the protocol....