Path: utzoo!attcan!uunet!husc6!rutgers!att!chinet!les
From: les@chinet.UUCP (Leslie Mikesell)
Newsgroups: comp.dcom.modems
Subject: Re: need help with xenix Kermit to PC procomm
Message-ID: <6360@chinet.UUCP>
Date: 23 Aug 88 13:48:02 GMT
References: <20302@neabbs.UUCP> <11744@oberon.USC.EDU> <6729@bigtex.uucp> <2877@ucdavis.ucdavis.edu>
Reply-To: les@chinet.UUCP (Leslie Mikesell)
Organization: Chinet - Public Access Unix
Lines: 46

In article <2877@ucdavis.ucdavis.edu> cck@deneb.ucdavis.edu.UUCP (Earl H. Kinmonth) writes:
>>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.
>
This is mostly an implementation problem and has been somwhat improved
in the current version for at least some flavors of unix.  The handling
of parity and timeouts is generally inefficient because it is written
to work on machines where the efficient modes do not work.  The inherint
problems of the protocol are:

small packet size 
    This is fixed in many current versions but both ends must
    support it and the user must explicitly request long packets.

indeterminate packet size
    This is the real killer for efficiency on unix.  Actual packet sizes
    are not exactly the agreed-upon size but generally slightly smaller
    to allow for the quoting mechanism for control characters.  This
    makes it impossible to get a packet in a single system call (or
    to set the SysV termio parameters to return exactly when the last
    character is received.  At least one version does a signal(), alarm(),
    setjmp(), and read() for *every* character when parity is set.

eighth-bit quoting
    This can be disabled in most versions but the user must do it
    explicitly at both ends, except for some versions (unix, at least)
    where it is tied to the parity setting.

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

I have to agree here. Re-writing the tty-specific code so that there
were separate versions of ckutio.c for at least three unix variations
(v7, BSD & SysIII/V) would help clear up the mass of #ifdefs.
 
Les Mikesell