Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!caen!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: <1991Jun12.184853.10990@hou.amoco.com>
Date: 12 Jun 91 18:48:53 GMT
References: <9106080216.AA26357@Kodak.COM> <1991Jun9.011029.9635@hou.amoco.com> <6989@vela.acs.oakland.edu>
Sender: news@hou.amoco.com
Organization: Amoco
Lines: 92

In article <6989@vela.acs.oakland.edu> rdthomps@vela.acs.oakland.edu (Robert D. Thompson) writes:
>In article <1991Jun9.011029.9635@hou.amoco.com> zjdg11@hou.amoco.com (Jim Graham) writes:
>>
>>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.
>
>	[ and the discussion goes on... ]
>>
>Thanks for the post Jim!!!

you're welcome....  :-)
>
>       You would be doing me a very big favor if you could 
>       discuss these implications for high-speed transfers, say
>       on 9600/V32.bis.

not sure what you're looking for....so I'll guess.  let me know if I missed
the point somewhere.

someone please correct me if I'm wrong, but if all we're talking about is
increasing the speed of the line, and assuming that the file xfer protocols
can keep up (which seems reasonable to me....), the only thing we're talking 
about is increasing the speed....  a protocol that is more efficient at 2400
will still be more efficient at 14,400.

that's assuming that the line speed is the only change.  now, if you add
error control, like V.42, you can play some games with protocol spoofing 
(like the Telebit does), and increase throughput somewhat.

Basically, the idea is this:  if you are already doing CRC-16 or CRC-32 
between the modems, why send yet another set of CRC overhead for end-to-end?
With protocol spoofing, the modem on the DTE that's sending the file examines
the packet and checks its CRC.  If the packet is valid, the modem goes ahead
and sends the ACK to the DTE.  if not, it sends a NAK.  It then (this is
pure assumption on my part --- I have no docs to prove this) probably strips
off the CRC overhead and sends more or less only the real data.  After the
packet has been received cleanly at the receiving end and passed the modem
connection's error control, it is delivered to the receiving DTE, which ACKs
or NAKs the packet (but this only really goes as far as the modem connected
to it).

I've used this a couple of times with the Telebit T-2500 at home, and it
certainly does seem to improve things a good bit.  I do not, however, have
any stats at all, and I rarely use X/Ymodem protocols (Zmodem serves me
quite well in most cases), so I can't really say with any certainty how much
impact it really seems to have.

Also, I would like to point out that much of what I'm just said is borrowed
from a document distributed by Telebit called tech.doc.  Their explanation is
much better than mine.....but I don't have it on disk here at work --- all I
have is a printout.  It is available for anonymous ftp...but I forgot what 
machines have it.

>       You may remember a few days back the postings about
>       YMODEM Batch.

sorry...I was out of town all last week, and missed a good portion of the
postings here.....


>       From what I gathered, YMODEM Batch (or is it G) provides
>       a streaming protocol...which I guess is sending without waiting
>       for an acknowledge.

nope...according to the Telebit document I referenced earlier, and assuming
I'm reading it right, Xmodem, Ymodem, Ymodem-G, Kermit, and UUCP-G all
require ACKs and NAKs as the xfer goes on.  I thought I'd seen something in
the Zmodem docs that said Zmodem also required ACKs (which didn't sound
right, since I never see TxD light up except when there are errors), but I
can't find it now.

>       Please elaborate (your posting above was very informative,
>       thanks!).

hopefully this one was at least a bit of what you were after......

later....
   --jim

Standard disclaimer....These thoughts are mine, 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.
------------------------------------------------------------------------------