info-kermit@ucbvax.ARPA (06/15/85)
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Info-Kermit Digest Fri, 14 Jun 1985 Volume 2 : Number 35
Known Bugs in MS-Kermit 2.28
Fixes to C-Kermit 4C Available for Unix, VMS, and Macintosh
Why is C-Kermit So Slow?
Kermit for Fortune 32/16?
----------------------------------------------------------------------
Date: Fri 14 Jun 85 18:30:52-EDT
Subject: Known Bugs in MS-Kermit 2.28
To: Info-Kermit@CU20B.ARPA
There are two major problems with MS-Kermit version 2.28:
1. When doing a GET command, incoming filenames are randomly truncated.
2. On the IBM PC family only, when escaping back from a terminal connection,
the system hangs.
We have a fix for problem 1 -- it's just a coding error (thanks to Dave
Tweten at NASA for pointing out the error and the fix). Problem 2 is more
serious: it comes from the use of incompatible assemblers and linkers. The
program depends upon its segments being in a certain order, and it instructs
the linker to put them in that order using the MSDMB and MSFINAL dummy
modules. However, it seems that certain assemblers defeat this technique. A
method is needed for insuring that the segments are in the desired order, no
matter what assembler and linker are used. While this problem is being
worked on, it should be noted that a version of the program that does not
have this bug is available in the .EXE and .BOO files we distribute, which
were built with an assembler/linker combination that ordered the segments as
desired.
A new release fixing problems 1 and 2 should appear within a few days.
Meanwhile, here's Dave's prescription:
Change 1 --
(original msfile.asm)
jne gofil4 ; No - get the filename.
; this bogusity copies the filename from the fcb into the data
(modified msfile.asm)
jne gofi4a ; No - get the filename.
; this bogusity copies the filename from the fcb into the data
Change 2 --
(original msfile.asm)
cmp flags.destflg,0 ; writing to printer?
jne gofil5 ; no, go on
(modified msfile.asm)
gofi4a: cmp flags.destflg,0 ; writing to printer?
jne gofil5 ; no, go on
------------------------------
Date: Fri 14 Jun 85 19:35:21-EDT
Subject: Fixes to C-Kermit 4C available for Unix, VMS, and Macintosh
To: Info-Kermit@CU20B.ARPA
The many messages reporting bugs in and/or suggesting fixes for Unix Kermit
4C(050) will not be reproduced here. Thanks to all those who sent them in,
particularly (in no special order) Bradley Smith at UCLA, Jim Bernard at U of
Delware, Kelvin Nilsen at U of Arizona, Larry Afrin at Clemson U, Dan Schullman
at DEC, Randy Huntziger at NLM, Frank Prindle at NADC, Martin Minow at DEC,
Marco Papa at USC, Jim Knutson at U Texas, Chris Maio at Columbia CS, Robert
Mark at USGS, Neal Holtz at UBC(?), David Ragozin at U of Washington, Dave
Tweten of NASA, and (of course) Herm Fischer (I think that's all of them;
apologies to anyone I missed). If you think this list is long, you should see
the messages themselves...
It should be apparent that this program has not settled down as much as was
hoped, and still further releases may appear over the summer. So if anyone
was thinking of posting it to net.sources... please don't!
C-KERMIT FOR UNIX, CHANGES FROM 4C(050) TO 4C(052), 14 JUNE 85:
. Fixed 8th-bit prefixing negotiation; sometimes C-Kermit would agree to do
it and then not really do it (applies also to Macintosh Kermit).
. Added minimal 2.9bsd support (further improvements solicited!).
. Trap and ignore QUIT signal, trap SIGHUP and handle like SIGINT.
This prevents lock files from being left behind after hangup or quit.
. Ignore SIGQUIT and SIGINT signals while inferior shell active -- let
inferior shell handle them.
. Allowed "-a name" to work when sending from stdin.
. Change hlptxt[] to contain less than 256 characters (for Xenix)
. Fixed bugs in determination of remote vs local mode.
. When stdin redirected, and remote/local status cannot be definitely
determined, assume local rather than remote so that local-mode commands can
still be used.
. Fixed bug that was making 16-bit machines erroneously report files not found.
. Change makefile symbol 3BX to ATT3BX (has to start with letter)
. Remove line continuations in the middle of strings in makefile.
. Fixed a couple errors in the Tower OS 1.02 support.
. Fixed a minor problem in V7 support.
. Got rid of the (void) casts in strxxx() invocations.
. For Sys III/V, open terminal in 7-bit, parity-enabled mode rather than 8-bit,
no-parity mode (some sites actually use parity).
. Change message "status report..." to "status report:" to avoid dot confusion.
. Replace Herm Fischer's ckudia.c with Dan Schullman's reworking of it, which
features support for more modems (in particular, the DEC DFxxx modems) and
more structured organization of the modem info, so support for new modems can
be added by making relatively straightforward table entries.
. Script command now accepts scripts that were continued on the command line
using \ (as advertised).
. Fixed minor syntactic problems in ckvtio.c for VAX/VMS.
The files are in KER:CK*.* on CU20B, available via anonymous FTP. Also
included is a new release of Macintosh Kermit, described briefly
below. Thanks to Doug Brutlag at SUMEX and Mike Meyer at U of
Wisconsin for pointing out the problems, and in some cases offering
fixes, and of course to Bill Schilit, now of Columbia CS, for doing
the work:
C-KERMIT FOR MACINTOSH, CHANGES FROM 0.8(28) TO 0.8(31), 14 JUNE 85:
. Built with new protocol modules from C-Kermit to fix 8th-bit-prefixing
negotiation.
. Added dragging and selecting of main window, for better coexistence with
desk accessories.
. Fixed COMMAND-SHIFT-1..COMMAND-SHIFT-9 problem. Since these keys are
special (they eject the diskettes, dump screens to files/printer, etc)
they were being ignored. This caused things like Control-@ and Control-^
to be ignored also. Add a new item to the SETTINGS menu that allows you
to enable or disable this action. The default is disabled.
. Fixed some default keymap definitions: Control-Y and Control-T were mapped
incorrectly. Control-' was mapped incorrectly. Functions were defined for
VT52 instead of VT100 keypad: Changed "?" to "O" in function definition
strings.
. Errors during and/or after CKMKEY save, decompile now handled better.
WARNING: A serious bug exists in Macintosh Kermit (this new release as well
as previous ones) which should be fixed in a forthcoming release (soon, I
hope): parity operations simply do not work correctly. Example: when parity
is set to "mark", Macintosh Kermit will discard any incoming underscore
characters; this prevents the Mac from receiving a file that requires more
than 63 packets, or from sending one that requires more than 33, assuming
said files contain no underscores (if they do, the hangup may occur sooner).
The problems fixed above were distracting enough to warrant early fixing, but
those who can live with them for another week or two are encouraged to wait
until an announcement can be made that the parity problem is fixed.
------------------------------
Date: Tue, 11 Jun 85 21:09:08 edt
From: xp!tony@nyu-cmcl2 (Tony Movshon)
Subject: Why is C-Kermit So Slow?
I've just been timing my backup from the Rainbow to the VAX (lightly loaded).
It's on a 9600-baud line, but is only transferring characters at about 140/sec.
By my lights, that's 14.5% efficient. Where'd the other 85.5% go?
I realize that the Kermit protocol expands the bytecount by about 25%, but
where's the rest of the time going?
Specifics:
to VAX 11/750, 2 MB memory, RA81 disk, 4.2BSD, no fancy
floating-point hardware, DMF32 port (DMA). Load average
about 1.7, 3-5 users. C-Kermit 4C (049), file type binary,
no parity.
from Rainbow 100A, 512k memory, RD51 10 MB Winchester. MS-Kermit
2.28.
I haven't timed it, but transfers seem to go considerably faster to my
11/24 running TSX-Plus using Kermit-11 V2.29.
Yours in puzzlement ...
Tony
------------------------------
Date: Wed 12 Jun 85 10:08:00-EDT
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Subject: Re: Why is C-Kermit so slow?
You have exactly the same setup as I do, except my VAX has more memory. I've
seen the speed vary a lot, and can't always explain it. In some cases, it's
appropriate to point the finger at 4.2bsd. Sometimes, the longer our system
is up, the slower it gets. Also, there are bugs in the DMF drivers that need
fixing (fixes are available from Usenix if you don't have them). Also,
sometimes the system will get VERY slow if one of the idle tty lines is being
blasted by noise -- that seems to happen to us a lot. The reason I mention
these items is that my measurements are a lot different from yours -- using
4.2bsd Kermit 4C(050) on a VAX-11/750 with load around 1.00 (with no special
line discipline, see below) against the Rainbow 100B running Kermit-MS 2.28,
transferring a 11372 character file with few repeated characters (so as not
to deceptively boost throughput because of run-encoding compression), I get:
Unix to PC: 28 seconds, or 406.0 cps (42% efficiency)
PC to Unix: 42 seconds, or 277.4 cps (29% efficiency)
These figures are not great, but they're better than your 140 cps by a good
bit.
Beyond the possible problems mentioned above, there's one inherent design
problem in BSD and probably most other Unixes as well -- the line is open in
raw mode for file transfer, but raw mode also turns on cbreak mode, which is
very expensive (more so when receiving data packets than when sending them).
BSD provides an alternate line discipline called "Berknet", which would have
been a LOT better for Kermit except that (a) it strips the 8th bit of
incoming characters, preventing efficient transfer of binary files, and (b)
it's hardwired to use LF as its only break character, whereas all the Kermit
programs in the world use CR. At Columbia, we fooled with modifying the
Berknet discipine to not strip the 8th bit, to be double-buffered, and to
allow specification of the break character; you can see some code in ckutio.c
under the KERLD conditional that evokes this line discipline. We found the
result was a Kermit that indeed ran a lot faster, but unfortunately we can't
really distribute the kernel modifications because we're too busy sending
ordinary Kermit shipments to get into the "send me your ATT and Berkeley
source licenses and we'll send you the code" business.
Short of fooling with the kernel, you should be able to speed C-Kermit up
perceptibly by recompiling with DEBUG not defined, to eliminate the many calls
to DEBUG that occur during normal operation, even when debugging information is
not being logged (and if you want to see sloooow, try transferring files with
debug logging turned on!).
- Frank
------------------------------
Date: Thu, 13 Jun 85 09:22 MDT
From: "Kevin W. Laurent" <KLaurent@DENVER.ARPA>
Subject: Kermit for Fortune 32/16?
We have a user with a Fortune 32/16 running FORPRO (similar to UNIX
version 7) who wants to use Kermit. Unfortunately, he doesn't have a C
compiler. Do you have a contact running Kermit on a Fortune? Thanks.
- Kevin Laurent <KLaurent@DENVER>
------------------------------
End of Info-Kermit Digest
*************************
-------