Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!ucdavis!deneb.ucdavis.edu!cck
From: cck@deneb.ucdavis.edu (Earl H. Kinmonth)
Newsgroups: comp.dcom.modems
Subject: Re: need help with xenix Kermit to PC procomm
Message-ID: <2877@ucdavis.ucdavis.edu>
Date: 23 Aug 88 06:02:59 GMT
References: <20302@neabbs.UUCP> <11744@oberon.USC.EDU> <6729@bigtex.uucp>
Sender: uucp@ucdavis.ucdavis.edu
Reply-To: cck@deneb.ucdavis.edu.UUCP (Earl H. Kinmonth)
Organization: University of California, Davis
Lines: 22

>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.

This is my experience.  I do many file transfers from a VAX
11/750.  Tests at 9600 baud (nominal) with the same file and same
loading conditions show kermit resulting a approximately four
times the billed time (cpu time + sys time) of xmodem.  Effective
transfer rates (measured at the receiving end) are typically
about 260 chars/sec with kermit.  Ascii file transfers run at 560
chars/sec under the same conditions.

I've found kermit so slow and so expensive (plus being so cranky)
over my leased line that I can get better and less expensive
results by running ascii transfers (base 85 encoded if the source
is weird or binary) twice and comparing each transmission or
simply compressing the file(s) to be transfferred with zoo or
compress and relying on the decompression process to catch munged
files which are then retransmitted.

By the way, I'm not a programmer, and perhaps should not comment,
but the code of ckermit impresses me as one holy rat's nest.