edwatkeys@pro-sol.cts.com (Ed Watkeys) (04/15/91)
What's the big deal with Kermit? Ther version I saw isn't that great. I'm not trying to put the thing down, but is there something about it that is special? What is the deal with the "Server" command in Kermit? I downloaded the application, but I never spent the three hours getting the docs... Ed Watkeys III Internet: edwatkeys@pro-sol.cts.com ProLine: edwatkeys@pro-sol UUCP: crash!pro-sol!edwatkeys ARPA: crash!pro-sol!edwatkeys@nosc.mil BitNET: edwatkeys%pro-sol.cts.com@nosc.mil
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (04/15/91)
edwatkeys@pro-sol.cts.com (Ed Watkeys) writes: >What's the big deal with Kermit? Ther version I saw isn't that great. I'm >not trying to put the thing down, but is there something about it that is >special? What is the deal with the "Server" command in Kermit? I >downloaded the application, but I never spent the three hours getting the >docs... Kermit is FREE and it works very well. It does not have an awesome interface but you didn't pay for it, so chill. Kermit's VT100 emulation is better than ProTerm's with certain systems (including tybalt) so I prefer kermit to ProTerm. The server command lets the other end issue file transfer commands, fetch directories (sometimes) and so on. It's useful when you dial a big system, run kermit, tell it to go into server mode, then escape to the command line and do the transfers. It's actually quite convenient. Kermit was designed to be portable and reliable above ALL other considerations. Think about that before you blast it. Todd Whitesel toddpw @ tybalt.caltech.edu
unknown@ucscb.UCSC.EDU (The Unknown User) (04/16/91)
In article <1991Apr15.072058.7969@nntp-server.caltech.edu> toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes: >edwatkeys@pro-sol.cts.com (Ed Watkeys) writes: > >>What's the big deal with Kermit? Ther version I saw isn't that great. I'm >>not trying to put the thing down, but is there something about it that is >>special? What is the deal with the "Server" command in Kermit? I >>downloaded the application, but I never spent the three hours getting the >>docs... >Kermit is FREE and it works very well. It does not have an awesome >interface but you didn't pay for it, so chill. Kermit's VT100 emulation >is better than ProTerm's with certain systems (including tybalt) so I prefer >kermit to ProTerm. Ugg, I certainly don't prefer Kermit to ProTERM, and don't think I'll see ANY program that I prefer to ProTERM (on any system) for a long time, if ever. The "big deal" with the Kermit protocol is that it doesn't care how many bits your connection is (7 or 8), and seems to work just fine under lots of other conditions where protocols like Xmodem barf. But unfortunately that makes it slow as hell.. About the speed of a 300 baud Xmodem transfer on a 2400 baud Kermit transfer. (Every time! I've done it multiple times and it's ALWAYS slow as molasses). So when I'm rlogged in or telnetted in somewhere and I can't use x/ymodem for some reason, I just text-trap programs. (Since they're in Binscii form, if there's ever an error it usually screws up the nice columns, so errors aren't a problem usually) I only have to do that when I call from home to ucscb through another site (rather than paying for the phone call).. so it's no biggie. -- /unknown@ucscb.ucsc.edu Apple IIGS Forever! WANT ULTIMA VI //e or GS?-mail me.\ \CHEAP CDs info-mail me. McIntosh Junior: The Power to Crush the Other Kids. /
platkus@en.ecn.purdue.edu (Shawn W Platkus) (04/16/91)
In article <8593@crash.cts.com> edwatkeys@pro-sol.cts.com (Ed Watkeys) writes: >What's the big deal with Kermit? Ther version I saw isn't that great. I'm >not trying to put the thing down, but is there something about it that is >special? What is the deal with the "Server" command in Kermit? I >downloaded the application, but I never spent the three hours getting the >docs... > I agree with you that Kermit isn't that great, and if you have ever used Kermit on unix or a mac or IBM pc or any other machine, it takes about 2 sec to figure out the Apple 2 version. But to answer your question, if you have to use Kermit protocol, what other program on the Apple 2 (e or GS) are you going to use? I do use Proterm's kermit for most things that I need kermit for, but it doesn't seem to be a true standard kermit. I use the Apple 2 Kermit for sending and receiving data from my HP48SX. I tried the kermit in proterm for this, but it royally screwed things up when receiving from the HP. Platkus
rlcollins@miavx1.acs.muohio.edu (Ryan 'Gozar' Collins) (04/17/91)
In article <14531@darkstar.ucsc.edu>, unknown@ucscb.UCSC.EDU (The Unknown User) writes: > But unfortunately that makes it slow as hell.. About the speed of > a 300 baud Xmodem transfer on a 2400 baud Kermit transfer. (Every time! I've > done it multiple times and it's ALWAYS slow as molasses). But Kermit now can have varied packet sizes, and with 1000 byte packets, it goes a lot faster. ------------------------------------------------------------------------------ Ryan 'Gozar' Collins Question for MAC Users: rlcollins@miavx1.BITNET |||| Power Without What IS the format of a rc1dsanu@miamiu.BITNET / || \ The Price!! MAC HFS floppy disk? R.COLLINS1 on GEnie ------------------------------------------------------------------------------
6500erik@ucsbuxa.ucsb.edu (Erik Adams) (04/17/91)
I have never used Kermit on my ][+, but I have used Kermit and Xmodem and Ymodem extensively on my Mac, and I have found that Kermit is slower, gives less control to the user, and is in general an inferior transfer protocol. Ymodem, on the other hand, is quick, sends file information with the transfer, so that well written software on the receiving end can tell you how long a coffee break you have :-). Now, maybe Kermit can do this too, but I have yet to find a program (for the Mac) that inplements this. I dislike Kermit, and wish ymodem was supported on my current host. Erik
daveh@ccwf.cc.utexas.edu (Dave Huang) (04/17/91)
In article <10611@hub.ucsb.edu> 6500erik@ucsbuxa.ucsb.edu (Erik Adams) writes: >I have never used Kermit on my ][+, but I have used Kermit >and Xmodem and Ymodem extensively on my Mac, and I have >found that Kermit is slower, gives less control to the user, >and is in general an inferior transfer protocol. Yes, Kermit is definitely slower than YModem, and even XModem. However, it gives _more_ control to the user (should you want it). You can adjust the packet length to something big (much better than the 83(?) than Kermit defaults to). Supposedly, you can get 2K packets, but IBM MS-Kermit only goes up to 2000 bytes, Mac Kermit goes up to 1000something, and Apple Kermit goes up to 250 :-( You can also set various packet parameters, such as the start-of-packet character, timeouts, and other useful (or useless, depending you what you need to do :-) parameters. >Ymodem, on the other hand, is quick, sends file information >with the transfer, so that well written software on the >receiving end can tell you how long a coffee break you have >:-). Now, maybe Kermit can do this too, but I have yet >to find a program (for the Mac) that inplements this. Normally, YModem is faster, but sometimes it doesn't work... I usually use YModem for downloading, but only for ShrinkIt archives, since the file length gets bumped up to an even block size (a multiple of 1024 bytes in this case). Also, I haven't gotten a YModem upload to work successfully. Kermit is more tolerant of 7-bit data lines, terminal servers, and any other stuff you might between your computer and the other end. Over here at UT, you have to go through two terminal servers (one Micom and one Cisco) to get to the workstations... >I dislike Kermit, and wish ymodem was supported on my >current host. I dislike Kermit too, but it always works! >Erik -- David Huang | Internet: daveh@ccwf.cc.utexas.edu | "How much is that hamster UUCP: ..!ut-emx!ccwf.cc.utexas.edu!daveh | in the window?" America Online: DrWho29 |
unknown@ucscb.UCSC.EDU (The Unknown User) (04/18/91)
In article <4882.280b0850@miavx1.acs.muohio.edu> rlcollins@miavx1.acs.muohio.edu (Ryan 'Gozar' Collins) writes: >In article <14531@darkstar.ucsc.edu>, unknown@ucscb.UCSC.EDU (The Unknown User) writes: >> But unfortunately that makes it slow as hell.. About the speed of >But Kermit now can have varied packet sizes, and with 1000 byte >packets, it goes a lot faster. Ymodem 1K is a little bit faster than Xmodem with 128 byte packets, but not THAT much. (I think the basic protocols are virtually identical, correct?) You're just doing less CRCs, and even doing 1/8 of them, it still seems you wouldn't speed up a whole transfer that much because the CRCs don't take up that much time. There's gotta be some other reason for the speedup. -- /unknown@ucscb.ucsc.edu Apple IIGS Forever! WANT ULTIMA VI //e or GS?-mail me.\ \CHEAP CDs info-mail me. McIntosh Junior: The Power to Crush the Other Kids. /
GRAY@ADMIN.HumberC.ON.CA (Kelly Gray) (04/18/91)
I have used Kermit on the Apple II+, and I agree, it is slow. In fact
I'd have to say that it is the slowest protocol around. It does however
have a major advantage. Kermit is the ONLY protocol I'm aware of that
can tolerate character substitutions by terminal servers. Kermit is
also highly tolerant of line noise, and doesn't mind a seven bit data
path (Xmodem REQUIRES an eight bit data path)
Kermit was written specifically for data transfer to and from mainframes
via the terminal ports. Speed, elegance, and just about everything else
was sacrificed for RELIABILITY. Kermit may be slow, but it keeps on going
long after everything else has given up.
<o_o>
_________________________ ________________________________________
/ \ / \
| Kelly Gray | The opinions expressed in the preceding |
| | message are not guaranteed to represent |
| GRAY@ADMIN.HumberC.ON.CA | any form of rational thought whatsoever |
\_________________________/ \_________________________________________/6500erik@ucsbuxa.ucsb.edu (Erik Adams) (04/19/91)
In article <91Apr18.091711edt.23337@ugw.utcs.utoronto.ca> GRAY@ADMIN.HumberC.ON.CA (Kelly Gray) writes: stuff deleted >Kermit was written specifically for data transfer to and from mainframes >via the terminal ports. Speed, elegance, and just about everything else >was sacrificed for RELIABILITY. Kermit may be slow, but it keeps on going >long after everything else has given up. This goes completely against my experiences with Kermit, Xmodem, and Ymodem. I have found Kermit to be extremely suceptible to line noise--it stops the transfer at the slightest hint of noise and I have to start over. A simple test: pick up the phone while transferring a file, and then put the phone back on the hook. More often than not, Kermit stops cold. Xmodem and Ymodem keep going. Or at least that's my experience.
toth@tellabs.com (Joseph G. Toth Jr.) (04/20/91)
In article <10684@hub.ucsb.edu>, 6500erik@ucsbuxa.ucsb.edu (Erik Adams) writes: > In article <91Apr18.091711edt.23337@ugw.utcs.utoronto.ca> GRAY@ADMIN.HumberC.ON.CA (Kelly Gray) writes: > > stuff deleted > > >Kermit was written specifically for data transfer to and from mainframes > >via the terminal ports. Speed, elegance, and just about everything else > >was sacrificed for RELIABILITY. Kermit may be slow, but it keeps on going > >long after everything else has given up. > > This goes completely against my experiences with Kermit, Xmodem, > and Ymodem. I have found Kermit to be extremely suceptible to > line noise--it stops the transfer at the slightest hint of noise > and I have to start over. A simple test: pick up the phone > while transferring a file, and then put the phone back on the > hook. More often than not, Kermit stops cold. Xmodem and Ymodem > keep going. Or at least that's my experience. Your experience? I find it very dificult to believe.. As far as Kermit, maybe (if you are using an ancient [very ancient] version of kermit, say 'Kermit 3.65'). My wife never bothers to check to see, or seems to care, if I am using the the phone. Her method of seeing if the phone is free is simply 'pick it up and see if Joe yells "Hey, I'm using the phone"'. I've never lost a transfer from one of these interruptions (I lost one when one of my kids picked up the phone, and it took too long (30 seconds or so) to restore the signal). I transfered the 'tbsp' demo (145xxx bytes) when there was a storm by my ofice (which I didn't know about), I had a clean file after the transfer even though there were 123 block retrys. As far as Xmodem, I simply do NOT believe that it is immune to line noise! It can't be. Xmodem performs too many of its operations using non Ascii characters. There are data networks that you might connect through that are not tolerant of binary transfers (just try sending a valid binary byte in a file that looks like (is) an XOFF character - bet you won't complete that transfer... Bet you have to reboot... ;^) On the plus side, I have used Xmodem at work from one computer directly to another using short haul modems, and I do like some of the features it provides (namely, letting me know how long the transfer will take - I don't know why Kermit doesn't do this). I don't have any experiences using Ymodem, so I won't say anything about it that I might regret later. -- ------------------------------------------------+--------------------- Maybe I shouldn't have done it, sarcasm is so | Joseph G. Toth Jr. seldom understood. Don't FLAME on me, please. | uunet!tellab5!toth
davewh@microsoft.UUCP (04/28/91)
Unknown speculates:
> There's gotta be some other reason for the speedup.
It's called overhead. For each packet of n bytes, there are 5 bytes
of overhead and then the waiting for the acknowledge. 1k of xmodem
packets works out to 8 ACK waits and 40 bytes of overhead. 1k of
ymodem packets works out to 1 ACK wait and 5 bytes of overhead. The
number of bytes of overhead don't start to become evident until
you've sent quite a number of packets (after 60k or something). The
real dead time is in the ACK waits. That's the theory as to why
Zmodem is faster than the various xmodem variants. the Zmodem sender
doesn't wait for ACKs, it just looks for NAKs. No NAK? Keep sending.
Now, 2 fast computers talking to each other don't suffer much on the
ACK waits. I noticed that putting an accelerator in your GS will
improve efficiency just a bit.
Dave Whitney Microsoft Corp, Work Group Apps dcw@goldilocks.lcs.mit.edu or
I wrote Z-Link and BinSCII - send me bug reports. {...}!uunet!microsoft!davewh
I only work here. All opinions herein aren't Bill's, they're mine.
"We're samplin' - Yeah we're doin' it. We take good music an' we ruin it."
-- "Rap Isn't Music"