Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!cs.umn.edu!uc!apctrc!voyager!zjdg11
From: zjdg11@hou.amoco.com (Jim Graham)
Newsgroups: comp.dcom.modems
Subject: Re: zmodem vs kermit
Message-ID: <1991Jun9.011029.9635@hou.amoco.com>
Date: 9 Jun 91 01:10:29 GMT
Article-I.D.: hou.1991Jun9.011029.9635
References: <9106080216.AA26357@Kodak.COM>
Sender: news@hou.amoco.com
Organization: Amoco
Lines: 58

In article <9106080216.AA26357@Kodak.COM> ctchou@Kodak.COM writes:
[....]
> recently I found out that changing the kermit's packet
> length from the default value (80) to 1000 increased the transfer rate by a
> factor of 5 or so. 

true...assuming the line conditions are good.  the reason you see an increased
throughput is the simple fact that you are sending a lot less overhead per
a given amount of real data.  if, on the other hand, the line was really bad,
suddenly you waste a lot of time every time you have to retransmit an errored
packet.  somewhere in between is a good compromise, which Zmodem tries to
find.

Let's say, for example, that you have a fixed amount of overhead, we'll pick
42 chars (42 comes to mind thanks to the tape of Hitchhiker's Guide to the
Galaxy that I've listened to 1000 times) for things such as packet
sequencing, CRC-16 or CRC-32 error control, etc., per packet, and the size of
the data section of the packet is your variable.  

Assuming no errors on the phone line, the larger the packet size, the less
overhead per byte of real data.  If, however, every so often you take a hit
on the phone line, you now have a very large packet to retransmit, which is
also costly as far as time goes.  As the line quality degrades, the overhead
required for CRC, etc., becomes small compared to the overhead for each
retransmitted packet.  And, of course, the larger the packet size, the higher
the probability of an error during that packet.  if your packet size is high
enough on a noisy line, there is the chance that NO packet may get through
w/o errors.  So, you reduce the packet size in hopes of just getting SOMETHING
through.....

On a very bad phone line, and I have definitely seen some of those, you will
notice that Zmodem drops the packet size to adjust for the quality of the
line --- looking for that compromise.  It searches for the breakeven point,
where the percent overhead due to smaller packet size is about the same as
the percent overhead due to retransmissions.  If the line cleans up, the
packet size works its way back up too.

> Since I cannot use zmodem on VAX, I cannot compare them.

why can't you use zmodem on the VAX?  I admit, I've never tried this, but
I seem to recall that the rzsz src is already prepared with #defines to
make VMS happy.  if not, I'm sure someone will reply to you with the steps
needed to make it work.

   --jim

Standard disclaimer....These thoughts are mine, not my employer's, and I'm
on my time...not my employer's.

------------------------------------------------------------------------------
Share and Enjoy!  (Sirius Cybernetics Corporation, complaints division)
73, de n5ial

Internet:  zjdg11@hou.amoco.com    or    grahj@gagme.chi.il.us
Amateur Radio:
   TCP/IP:    jim@n5ial.ampr.org (44.72.47.193)
   Packet:    BBS went QRT for good...still searching for new one.
------------------------------------------------------------------------------