mullen@b.gp.cs.cmu.edu (John Mullen) (08/17/88)
I was wondering if Kermit is worth buying. The question that I have is how long does it take to download a ~4K file from a Commodore to a VAX? Any/all help will be greatly appreciated. Thanks. Also, is there a certain Kermit package that is quicker than another? And are there any factors that may determine how long the file transfer will take? John PS: The Commodore is a Commodore 64 .signature ????? John J. Mullen mullen@b.gp.cs.cmu.edu Part-Time Operator, Computer Science Office: WeH 3610, Office Phone: (412) 268-2607
prindle@NADC.ARPA (Frank Prindle) (08/18/88)
1. Kermit is definitely worth buying considering that it is FREE! Kermit is not a commercial product, but a series of implementations of a public domain protocol, where each of the implementations is also public domain. C64 Kermit was originally developed by Eric Lavitsky and others. It has recently been refined considerably by Ray Moody. It is available for the downloading from Columbia University or from many C64 oriented bulletin board systems. If you order it from Dr. Evil Labs on disk, Ray will charge $5.00 only for the diskette, postage, and handling; the software itself is FREE. 2. To upload a 4K file from C64 to VAX takes approximately 1 to 2 minutes at 1200 baud, depending on the handshake response time of the VAX system (i.e. how busy it is), and what kind of file is being transferred. Downloading is just a tad faster. 3. There really is only one "official" Kermit package for the C64, though it is available in several historically subsequent versions, the latest being version 2.1 (highly recommended for C128 owners because of it's support for the 80 column chip and it's VT100 emulation). Older versions (pre 2.0) supported a 25 line by 40 column, or 25 line by 80 column VT52 emulation on the C64 40-column screen only. The Kermit protocol may be embedded in other commercial terminal packages that are available, but these are not the "official" kermit implementation. 4. The factors that limit file transfer speed are: a. Baud rate: 1200 baud means that the theoretical maximum transfer rate is about 130 bytes/second. b. Packet Size: Kermit packets are limited to a maximum length of 96 bytes; after each 96 byte data packet is sent by the sending Kermit, the receiving Kermit must validate the packet and transmit either an ACK or NAK packet (about 5 or 6 bytes) back to the sender. c. Quoting: To avoid communication problems over a wide variety of networks, Kermit only utilizes the 95 printing ASCII characters and SOH (^A). A file that contains any other bytes (e.g. a binary file or PRG file) must have each non-printing character quoted by preceeding it with a special printing character. Thus a file containing many bytes in the ranges 00-1f, 7f-9f hex will take twice as long to transfer as a text file. Quoting increases even more if the communication path doesn't support 8 bits of data. d. Disk Read/Write speed: We all know what this is on the C64! Reads or writes to disk cause occasional delays in transmission. e. Response time of the remote system: If the remote host is a busy time sharing system, serving many users, it may not be able to validate packets and provide ACK responses quickly. f. Communication line delay: Telephone electronics between you and the remote host, if over long distance circuits, can cause noticable slowdown if delays are a substantial fraction of a second. All in all, therefore, the Kermit error-correcting protocol reduces a 1200 baud connection to an effective text transfer speed of typically 60 bytes/ second; obviously there can be considerable variation, with PRG files slowed down by about 25% more due to quoting. One really nice feature of Kermit protocol is that it supports multiple file transfers with a single command. However, C64 Kermit currently supports this only for downloads: you can start a transfer of 10 files, then go do something else for a half hour or so and come back when they are all done - you don't have to babysit each file. Future versions of C64 Kermit should support this for uploading too. For a complete discussion of the Kermit protocol by it's creators, Frank da Cruz and Bill Catchings, consult the June and July 1984 issues of Byte magazine. They have also published a book on Kermit. Sincerely, Frank Prindle Prindle@NADC.arpa
dg@lakart.UUCP (David Goodenough) (08/18/88)
From article <2726@pt.cs.cmu.edu>, by mullen@b.gp.cs.cmu.edu (John Mullen): > I was wondering if Kermit is worth buying. The question that I > have is how long does it take to download a ~4K file from a Commodore > to a VAX? Any/all help will be greatly appreciated. Thanks. Also, > is there a certain Kermit package that is quicker than another? And > are there any factors that may determine how long the file transfer will > take? > > John > PS: The Commodore is a Commodore 64 First - while Kermit is worth having a copy of, it is not worth "buying" - you can download a free copy from Q-link, or get it from other P.D. sources (If I'm pressed I can even upload and E-mail you a copy Mr. Mullen). As for data transfer speed: I use Kermit to X-fer stuff from our Unix machine at work to my CP/M (gasp) machine at home: Kermit takes (about) 10% extra bandwidth to transmit a file (assuming text - if it's a binary it gets worse). So 4096 characters of data will need about 4500 characters transmitted over the line. Now 300 Baud is 30 CPS, hence 4500 chars take 150 seconds - 2.5 minutes, and at 1200 it's under a minute (about 40 sec). A fair estimate that will put you in the correct ballpark for data transmission is that a K takes about 10 seconds @ 1200 baud. -- dg@lakart.UUCP - David Goodenough +---+ | +-+-+ ....... !harvard!cca!lakart!dg +-+-+ | +---+
berger@clio.las.uiuc.edu (08/19/88)
I'd say that C-64 Kermit is worth buying. For one thing, it's free.
For another, it gives you a good, functional, 80-column mode and
adequate vt-100 and vt-52 emulation.
Mike Berger
Department of Statistics
Science, Technology, and Society
University of Illinois
berger@clio.las.uiuc.edu
{ihnp4 | convex | pur-ee}!uiucuxc!clio!bergeriachetta@ec.ecn.purdue.edu (Richard N Iachetta) (04/06/91)
What is the latest version of Kermit 64/128? Basically what I need to know is, is there a version that will support packet lengths longer than 94 bytes (I think that is the length. If its not, it is close). Is it just me or does that seem to be a ridiculous packet length. The overhead between packets is longer than the packet transmission time. Thanks in advance. Rich iachetta@ecn.purdue.edu
nrossi@jarthur.Claremont.EDU (Nick Rossi) (04/06/91)
In article <1991Apr5.201357.7658@noose.ecn.purdue.edu> iachetta@ec.ecn.purdue.edu (Richard N Iachetta) writes: >What is the latest version of Kermit 64/128? Basically what I need to know >is, is there a version that will support packet lengths longer than 94 bytes >(I think that is the length. If its not, it is close). Is it just me or does >that seem to be a ridiculous packet length. The overhead between packets is >longer than the packet transmission time. Thanks in advance. > >Rich >iachetta@ecn.purdue.edu For standard Kermit, the maximum packet length is 94 bytes. Yes, there is a lot of overhead in Kermit which makes it a very inefficient protocol (which is why I dislike it so much). But it was designed to operate on ANY computer environment, by forcing packets to consist of only printable characters and such. I seem to recall using a Kermit program on an IBM which was sending 1024 byte packets, but perhaps I was looking at the wrong thing on the screen or something, as I haven't been able to reproduce it. ------------------------------ +---------------------------------+ Nick Rossi, '93 | SONY | ------------------------------ | | Harvey Mudd College | Because caucasians are just | (ooo HELL is a place on earth) | too damn tall. | ------------------------------ +---------------------------------+
cs4344af@evax.arl.utexas.edu (Fuzzy Fox) (04/07/91)
In article <1991Apr5.201357.7658@noose.ecn.purdue.edu> iachetta@ec.ecn.purdue.edu (Richard N Iachetta) writes: >What is the latest version of Kermit 64/128? Basically what I need to know >is, is there a version that will support packet lengths longer than 94 bytes >(I think that is the length. If its not, it is close). Is it just me or does >that seem to be a ridiculous packet length. The overhead between packets is >longer than the packet transmission time. Thanks in advance. Yes, but Kermit is the only protocol that can be used over 7-bit lines, which is the only connection we have to our university. Better a bad connection than no connection. The latest Kermit is 2.2sp, which is speed-patched for 2400, and available at Milton. It does not support long packet lengths, and even if it did, the other Kermit (ie, the one on your host computer) probably wouldn't either. I have found that one of the reasons that Kermit is slow is because the Commodore version is slow. My IBM PC sends and receives files much faster with Kermit, although still only about 120 cps on a 2400 line. When will 7-bit Zmodem get here? -- David DeSimone, aka "Fuzzy Fox" on some networks. /!/! INET: an207@cleveland.freenet.edu / .. Q-Link: Fuzzy Fox / --* Quote: "Foxes are people too! And vice versa." / ---
mroussel@alchemy.chem.utoronto.ca (Marc Roussel) (04/08/91)
In article <11571@jarthur.Claremont.EDU> nrossi@jarthur.Claremont.EDU (Nick Rossi) writes: >For standard Kermit, the maximum packet length is 94 bytes. Yes, there is >a lot of overhead in Kermit which makes it a very inefficient protocol (which >is why I dislike it so much). But it was designed to operate on ANY >computer environment, by forcing packets to consist of only printable >characters and such. I seem to recall using a Kermit program on an IBM which >was sending 1024 byte packets, but perhaps I was looking at the wrong thing >on the screen or something, as I haven't been able to reproduce it. I don't think that this is quite right. The packet length in Kermit is arbitrary. In fact, the initial handshake between the two computers includes packet length information. (Transmission is then undertaken at the largest packet length allowed by both Kermits. The "set send/receive packet length" commands merely tell Kermit how large a packet you wish to allow it to use. Why you'd ever want this to be less than the maximum, I don't know.) Kermit-65 can't handle packets any greater than 96 bytes (according to my manual). This maximum has to do with the amount of memory available for buffering I think. On the other hand, the latest versions of MS-Kermit and C-Kermit can handle packets up to 1Kbytes. I hope I got this right. (I'm relaying second-hand information here, not first-hand knowledge.) If I didn't, I hope someone will set me straight. Marc R. Roussel mroussel@alchemy.chem.utoronto.ca
nrossi@jarthur.Claremont.EDU (Nick Rossi) (04/08/91)
In article <1991Apr7.205934.20408@alchemy.chem.utoronto.ca> mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes: >In article <11571@jarthur.Claremont.EDU> nrossi@jarthur.Claremont.EDU >(Nick Rossi) writes: >>For standard Kermit, the maximum packet length is 94 bytes. Yes, there is >>a lot of overhead in Kermit which makes it a very inefficient protocol (which >>characters and such. I seem to recall using a Kermit program on an IBM which >>was sending 1024 byte packets, but perhaps I was looking at the wrong thing >>on the screen or something, as I haven't been able to reproduce it. > I don't think that this is quite right. The packet length in Kermit is >arbitrary. In fact, the initial handshake between the two computers >includes packet length information. (Transmission is then undertaken at >the largest packet length allowed by both Kermits. The "set send/receive >packet length" commands merely tell Kermit how large a packet you wish to >allow it to use. Why you'd ever want this to be less than the maximum, >I don't know.) Kermit-65 can't handle packets any greater than 96 bytes >(according to my manual). This maximum has to do with the amount of memory >available for buffering I think. On the other hand, the latest versions of >MS-Kermit and C-Kermit can handle packets up to 1Kbytes. > I hope I got this right. (I'm relaying second-hand information >here, not first-hand knowledge.) If I didn't, I hope someone will set me >straight. Marc R. Roussel mroussel@alchemy.chem.utoronto.ca The reason Kermit (standard Kermit, anyway) won't support packet lengths longer than 96 bytes is because only one byte in a packet is available for negotiating the packet size. This byte must be in the printable character range (as are all bytes in Kermit packets), and so it must have a value between 32 and 126. Subtract 32 from this range, and you have a value between 0 and 94. The packet length represents the length of everything after the length byte, so the actual maximum size is 96 (packet plus length byte plus start-of-header). The maximum length is determined by the buffering size of the receiving computer. For some systems this is not a problem, but again, Kermit was designed to work on ANY environment, some of which may have smaller buffers. ------------------------------ +---------------------------------+ Nick Rossi, '93 | SONY | ------------------------------ | | Harvey Mudd College | Because caucasians are just | (ooo HELL is a place on earth) | too damn tall. | ------------------------------ +---------------------------------+