Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ll-xn!mit-eddie!bloom-beacon!tut.cis.ohio-state.edu!cs.utexas.edu!ut-emx!mybest!bigtex!james
From: james@bigtex.uucp (James Van Artsdalen)
Newsgroups: comp.dcom.modems
Subject: Re: need help with xenix Kermit to PC procomm
Message-ID: <6729@bigtex.uucp>
Date: 22 Aug 88 18:58:11 GMT
References: <20302@neabbs.UUCP> <11744@oberon.USC.EDU>
Reply-To: james@bigtex.UUCP (James Van Artsdalen)
Organization: F.B.N. Software, Austin TX
Lines: 54

In article <11744@oberon.USC.EDU>, blarson@skat.usc.edu (Bob Larson) wrote:

> >Kermit is VERY  slow on binary files and many versions are
> >incompatible. (also the 'super' implementations)

> This is just plain wrong as far as I know.  The main "incompatability"
> problem I know of is different default parity.  (Parity is easily
> settable in most implementations, and usually can go into an
> initialization file.)  All versions of kermit are able to transfer
> files to each other.

Not true.  Consider kermit implemented on the "Fido" BBSs.  It may work
now, but for a long time it did not.

> (Unlike XMODEM, YMODEM, ZMODEM, WXMODEM, etc.)

This statement makes no sense.

If you can find an incompatible version of Zmodem, let's hear about
it.  The primary problem with Xmodem (and to a lesser extent with
Ymodem) is naming: people have a habit of adding features to the
protocol and continuing to call it Xmodem.  Some people outright used
the name Ymodem for protocols that aren't really Ymodem but simply
extensions to Xmodem.

> A few backward implementations are not able to handle binary files
> over 7-bit communications lines.

Ah!  "All versions of kermit are able to transfer files to each
other."?

> [..] Kermit does have more overhead than
> XMODEM on binary files, about 27% on random binary, less than that on
> most real files.  This does not seem "VERY" slow in comparison to me.

Kermit has more overhead no matter how you measure it.  The packets
have high overhead, and the implementations have high resource
requirements on the host processor.  Windowing Kermit tends to have
very high overhead.

> [...]  I have yet to see a
> comparison of ZMODEM to windowing kermit from a non-biased source, I
> would expect windowing kermit to be about 5% slower on a typical file
> mixture.

Well, Chuck Forsberg has implemented both - his Pro-YAM does support
windowing Kermit.  His numbers are likely as accurate if not more so
than anyone else's.  The 5% range seems a little low to me, but the
real price is paid if there are network delays.  Doing Kermit over
Telenet is an exercise in futility - 25cps or so, whereas Zmodem does
116cps+, just like it would on a local call (no comparison using
windowing Kermit, because I don't know anyone who supports it)...
-- 
James R. Van Artsdalen    ...!uunet!utastro!bigtex!james     "Live Free or Die"
Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746