DECSYSTEM-20 KERMIT 5.1 UPDATE NOTES Frank da Cruz The Kermit Project Columbia University http://www.columbia.edu/kermit/ 3 December 2003 Summary: . 5.1(263) 2001-01-28: Long packets. . 5.1(264) 2001-08-06: Buffered packet reading. . 5.1(266) 2003-08-03: ARPANET/Internet improvements, bug fixes. 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 DEC-20 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). "kuser" is 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. (End)