DECSYSTEM-20 KERMIT 5.1 UPDATE NOTES
Frank da Cruz
The Kermit Project
Columbia University
http://www.columbia.edu/kermit/
6 Jan 2006
Summary:
. 5.1(263)
. 5.1(264)
. 5.1(266)
. 5.1(186)
etc.
2001-01-28:
2001-08-06:
2003-08-03:
2006-01-06:
Long packets.
Buffered packet reading.
ARPANET/Internet improvements, bug fixes.
Decimal version number, fix restoring term modes,
Version 5.1(263) of DECSYSTEM-20 KERMIT, released 28 January 2001 (the
first change in 13 years) supports long packets. This was never done
before because long packets would break the DEC-20 front end hardware and
OS (PDP-11/40 with DH11s and RSX20F) and crash the DEC-20. But as far as
I know, no real KL-10 based DEC-20s exist any more; all current DEC-20s
are either 2020s (which don't have PDP-11 front ends), non-DEC clones, or
else running on other hardware under emulation. So now you can use DEC20
Kermit to transfer files with packets up to 9K in length; the previous
maximum was 94 bytes. This gives speed improvements up to about a factor
of 20 (i.e. 2000%). Long packets have been tested only on Telnet
connections INTO the DEC-20. They have not been tested on serial
connections or on outbound connections of any kind.
This update was made in anticipation of the release of publicly available
PDP-10 emulators running under Linux, Windows, or other common platforms.
Since the emulator will not necessarily have Internet support, a way is
needed to import and export files: DEC-20 Kermit (the very first Kermit
program) lives again! Now when you log in to the DEC-20 (or emulator)
from
a PC or other computer running a Kermit-capable terminal emulator, you
can
run DEC-20 Kermit to exchange files with your computer, and the transfers
will not be as agonizingly slow as they would have been without this
update.
To use long packets, tell the file receiver (DEC-20 Kermit or the other
Kermit) to:
SET RECEIVE PACKET-LENGTH xxxx
where xxxx is the desired packet length, e.g. 1000, 2000, 4000, etc.
Obviously if some big length doesn't work, try a shorter one (in my
testing,
all lengths up to 9000 worked).
Version 5.1(264), 6 August 2001, adds another performance improvement.
Previously, file-transfer packet input was read a byte at a time with BIN
(Byte In) monitor calls, which is quite expensive. This was not a
bottleneck in the 9600bps days, but now it is. So I changed the packet
character-input routine (inchar) to read in gulps: SIBE to see what's
waiting, SIN to read that many, and BIN only if nothing is waiting or
nothing was read by SIN. On my NYC-to-CA Telnet connection, sending a
file
to the DEC-20, performance improved between 30% and 100% over several
trials. That's with a 400K file, using 4000-byte packets and a 1K packet
input buffer. STAT after a RECEIVE command shows the number of ILDBs
(load
byte from buffer), SINs, and BINs. The fewer SINs and BINs, the better.
The maximum SIN gulp always seems to be 251, which is probably a
limitation
of the underlying TCP/IP stack, so there would seem to be no point in
increasing the SIN buffer size. Note: Packet sending was already
buffered;
packets are sent with a SOUT% in spack.
A few cautions are in order about using DEC-20 Kermit as the file
transfer
partner of modern Kermit programs:
1. DEC-20 Kermit can accept unprefixed control characters except for
0, 1, 3, 13, 15, 17, 19, and 20, and their 8-bit doppelgangers. In
case sending to the DEC-20 fails consistently, tell the other Kermit
to
SET PREFIXING ALL and SET CLEAR-CHANNEL OFF. (Instead of SET
PREFIXING
ALL you could also use SET CONTROL PREFIX MINIMAL, SET CONTROL PREFIX
0 1 3 13 15 17 19 20).
2. There are no sliding windows, streaming, or other modern
conveniences.
They might improve performance a bit more, but not nearly as much as
long packets and buffered reads. The lack of these features does not
cause a problem since they are negotiated automatically in the
protocol. (Adding them, on the other hand, would be a major
project.)
3. DEC-20 Kermit does not support Attribute packets so size, type, and
date information is not relayed automatically from sender to
receiver.
4. DEC-20 Kermit doesn't have SET FILE TYPE { TEXT, BINARY } commands
like
other Kermits do. Nevertheless, it is possible to transfer text,
native 36-bit binary, and foreign 8-bit binary files back and forth,
but you must follow the instructions in the manual. Here's a brief
summary:
Let's say you have a PC running DOS, Windows, or UNIX with MS-DOS Kermit,
C-Kermit, or Kermit 95, that has a TELNET connection to a DEC-20 or
emulator. Then:
To transfer an ASCII text file between the DEC-20 and the PC:
Tell the PC Kermit to "set file type text" and then transfer the
file.
This is equivalent to FTP TYPE ASCII.
To transfer a 36-bit binary file between the DEC-20 and the PC:
Tell the PC Kermit to "set file type binary".
Then transfer the file.
This is equivalent to FTP TYPE BINARY.
To transfer an 8-bit binary PC file between the PC and the DEC-20:
Tell the PC Kermit to "set file type binary".
Tell DEC-20 Kermit to "set file byte 8".
Then transfer the file.
This is equivalent to FTP TYPE TENEX.
Among other tests, the new Kermit-20 was used to receive its own source
file,
which was then assembled, linked, and run. The new KERMIT.EXE was used
to send itself to a PC, and then to receive the copy of itself that it
had just
sent, and then this copy was run to do the same things again.
Installation instructions:
Download the new Kermit source (one file) in text mode from the
Kermit Project archive in text ("ASCII") mode:
ftp://kermit.columbia.edu/kermit/d/k20mit.mac
Note: this is a MACRO-20 source file; it is not any kind of "package",
tarball, ZIP archive, compressed, encrypted, or anything else. It's
just PLAIN TEXT (if you use DEC-20s you know what plain text is).
Rename it to KERMIT.MAC, then:
load kermit
save
This produces a KERMIT.EXE file, which is DEC-20 Kermit. Install it
somewhere in SYS:, or else redefine SYS: to include the directory where
KERMIT.EXE is, or run it out of its own directory with "r kermit".
Give it execute permission, e.g. P775252. Documentation is here:
Plain text:
ftp://kermit.columbia.edu/kermit/e/kuser.doc
ftp://kermit.columbia.edu/kermit/d/k20mit.doc
PostScript:
ftp://kermit.columbia.edu/kermit/e/kuser.ps
ftp://kermit.columbia.edu/kermit/d/k20mit.ps
The manual has not been updated (this document is the update).
is
"kuser"
the old 1980s Kermit User Guide; "k20mit" is the DEC-20 chapter. Note
that
".DOC" is used in the original sense; these are not MS Word files. All
files listed above should be transferred in text ("ASCII") mode.
Note: DEC-20 Kermit is not a Telnet client, and so can't make Telnet
connections. But since it knows how to make serial connections, most of
the needed code is there; only the network-specific pieces for opening
the
connection (gethostbyname, connect, etc) and executing at least a minimal
TELNET protocol are missing and could be added in event that a PDP-10
emulator appears that is capable of running TOPS-20 6.0 or later, with
built-in ARPANET support and Ethernet drivers. Earlier TOPS-20 versions
required an outboard IMP Interface (AN20) (except maybe TOPS-20 4.1 on
the KS-10).
Also note that there is no kind of internationalization whatsoever; no
character-set translation and no special support for 8-bit text. While
you
might be able to transfer 8-bit text (e.g. Latin-1), you can't have 8-bit
filenames because TOPS-20 doesn't support them.
--------------------------------From Tom De Bellis, December 2003:
I merged in [Mark Crispin's] PANDA network binary mode under a
conditional. If the PANDA MTOPR% fails for any reason, then I revert to
the old way of poking the TAC or host. While I was at it, I fixed a
couple of minor bugs. In particular, reslin and subroutines now always
load the terminal jfn, as there were cases where they were trying to
clear
the output buffer of .FHSLF! I wonder what CFOBF%ing a fork should do?
Clear the memory? :-)
Next, I put in code to automatically recognize whether the selected line
is a TVT or not and put the line into binary mode. In particular,
(stable) 6.0 series monitors have the NTINF% Jsys which says what kind of
line you're on. The feature definitely works in 7 series monitors.
However, just in case it gronks, I fall back to doing it the old way with
STAT% (which also works).
I updated the user interface a little to control the new functionality.
I
added an additional keyword to the set TVT-Binary command: 'automatic'
and
made it the default. When Kermit is in automatic TVT-Binary negotiation
mode, it uses the above code to determine TVT-ness. However, I allow
overrides 'set TVT-Binary {on|off}' to maintain compatibility. Finally,
I
updated the program's internal help documention.
Program performance in certain cases has been stellar. While running
C-Kermit on MAC OS 10.2, I was getting data rates from the 20 that
exceeded what I could transfer with FTP (which is part of the reason that
I am re-writing part of FTPSER). Data rates to my laptop running Windows
2000 have been good, although not as good as the iMac.
The problem with assymmetric transfer speeds with Kermit turns out to be
with KLH-10 itself. For some reason, it is faster to transfer files out
of the 20 than it is to transfer them into the 20. As an example, for a
104 page file, I got 7.54 KBs/s when I put the file to the 20 from my
Windows 2000 laptop. When I pulled the file (get), my transfer rate went
to 39.90 KBs/s, more than five times as fast.
(End of Tom's remarks)
Translation: your mileage may vary according which PDP-10 emulator you
are
using (or which PDP-10!); as far as I know there's only one Telnet server
for TOPS-20, so that shouldn't be a factor. When I added long packet
support in 2001, it was done on real KL-10 hardware (XKL), and I didn't
notice any big discrepancy in send and receive rates over a Telnet
connection, but since the XKL is no longer accessible to me I can't
repeat
the experiment.
Tom's new version was used to download itself from KLH-10, along with a
2MB JPG ("set file byte 8") for the DEC-20 historical archive (from when
Tom was in Columbia's DEC-20 Systems Group in the 1980s). It took a few
tries to get the JPG across. Unlike when running Kermit-20 on the XKL, I
had to crank the packet length back to something like 500, and still got
a
5% (correctable) error rate.
Tom's new version was installed at the Kermit Project ftp site 3 Dec
2003.
--------------------------------From Tom De Bellis, January 2006:
. Properly save and restore terminal dimensions. The original code
didn't
work (e.g.) for 132 columns.
. Change program version number to be decimal rather than octal, to
agree
with EXEC.
. Make Kermit work after QUIT, DETACH, and CONTINUE
See comments at top of code for details.
To this I added version date display to the startup herald and SHOW
VERSION
command. Why not? It's been 25 years. This is version 5.1(186) 6-Jan2006.
As a concession to modern times, I also made a PDF version of the Kermit20
manual:
ftp://kermit.columbia.edu/kermit/d/k20mit.pdf
Other notes: it seems to be almost impossible to transfer files on a
Telnet
connection into the KLH10 emulator with Kermit at speeds anywhere above
200cps. Transfers out of it go at more like 7000cps. But when Kermit-20
is
receiving, the packet length has to be 80 or less or the whole session
freezes forever. Even with 80 byte packets there are lots of errors and
retries, usually enough to kill the transfer if the file is long enough.
I
don't know if it's KLH10 itself, or the firewall/NAT in between here and
there. It doesn't happen on real DEC-20 hardware (e.g. Telnet into the
former TOAD-1). The behavior is reminiscent of RSX-20F when data was
coming
in too fast -- it would simply set the DH11 line speed to 0 for a second
or
to, to give itself a chance to catch up.
A couple things that are very annoying could be easily fixed:
. There's no way to escape out of the Kermit-20 packet reader.
C-Kermit uses ^C^C^C, which has proven safe and effective.
This should be added to rpack.
. Kermit-20 doesn't let the GET command be issued when it's in
remote mode, which inhibits autoupload. Just take the check out.
A somewhat larger project would be to implement Attribute packets.
As noted earlier, it would be nice to have a Telnet client too, if only
for use by old-timers, since Telnet servers have virtually disappeared
from
all modern platforms (despite the fact that Telnet secured by SSL, TLS,
or GSSAPI is more secure and more capable than the SSH setup that
displaced
it -- and FTP into the bargain).
- fdc, 6 Jan 2006
(End)