jamesm@sco.COM (James M. Moore) (06/20/89)
One thing I've noticed about Kermit (using 9(40)) is that the transfer rate seems very slow. I'm running a 9600 baud direct connect to a XENIX box, and kermit reports the effective baud rate for file transfers at about 1200. Is there any way to get this speed up, or is this just something I have to live with? -- James Moore jamesm@sco.com
nghiem@walt.cc.utexas.edu (Alex Nghiem) (06/28/89)
[question about why MacKermit seems slow during file transfer at 9600 baud] You need to change your send and receive packet size to 1000 and set your block check type to 3 (CRC) to ensure 99.9% error correction. If you use the default settings, your packet size will be only 94 bytes. You will lose throughput because of the overhead needed to calculate a checksum for each of the 94 byte blocks. Cheers...
lih@cunixc.cc.columbia.edu (Andrew Lih) (06/28/89)
In article <3769@viscous.sco.COM> jamesm@sco.COM (James M. Moore) writes: >One thing I've noticed about Kermit (using 9(40)) is that the transfer >rate seems very slow. I'm running a 9600 baud direct connect to a XENIX >box, and kermit reports the effective baud rate for file transfers at >about 1200. Is there any way to get this speed up, or is this just something >I have to live with? One nice thing about version 0.9(40) is that you can adjust the packet size of the send/receive packets. Kermit normally uses a packet size of 94 bytes. You can significantly increase throughput by doing several things: 1. Increase the packet size. If you increase the size to a higher byte count (512 bytes or even up to 1024 bytes) more data will be transfered without all of the packet headers as overhead. This usually gives you the most dramatic increase. 2. Adjust the block check accordingly. MacKermit presently supports three types of block check (1,2,3). Block check type 1 is a simple checksum, which is the fastest to calculate. If you have a very clean line (dedicated line, or direct connect) then this is all that you will need. Block check type 3 is a full CRC check, so it will take a while to compute this for each block. On a Mac Plus there is a noticable slowdown. Use a higher block check when there is more chance for an error. 3. Download to a quick storage medium. If it is possible, download to a RAM disk, and second to a hard disk. Downloading to a floppy will slow things down since reads/writes to a floppy are rather slow. If you have a noisy line, then you will want to decrease your packet size (perhaps no larger than 512 bytes) since retransmission of anything larger will bog down your file transfer. Hope this helps! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= """"""" Andrew "Fuz" Lih Columbia University Center | @ @ | Instructional Computing for Computing Activities < ^ > \ - / lih@cunixc.cc.columbia.edu AJLUS@CUVMB.BITNET --- lih@heathcliff.cs.columbia.edu ...rutgers!columbia!cunixc!lih =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
mjohnson@Apple.COM (Mark B. Johnson) (06/29/89)
In article <14586@ut-emx.UUCP> nghiem@walt.cc.utexas.edu (Alex Nghiem) writes: >[question about why MacKermit seems slow during file transfer at 9600 baud] > >You need to change your send and receive packet size to 1000 and set >your block check type to 3 (CRC) to ensure 99.9% error correction. If >you use the default settings, your packet size will be only 94 bytes. >You will lose throughput because of the overhead needed to calculate >a checksum for each of the 94 byte blocks. You don't need to set block check to 3 (it can stay at 1) to use long packets in Kermit. Setting it to 3 actually slows the transfer rate. To use long packets, you'll need version 0.9(40) of MacKermit and at preferably edit history (70) of C Kermit on your Unix machine... Mark B. Johnson AppleLink: mjohnson Developer Technical Support domain: mjohnson@Apple.com Apple Computer, Inc. UUCP: {amdahl,decwrl,sun,unisoft}!apple!mjohnson "You gave your life to become the person you are right now. Was it worth it?" - Richard Bach, _One_
stuartb@microsoft.UUCP (Stuart Burden) (06/30/89)
In article <3769@viscous.sco.COM> jamesm@sco.COM (James M. Moore) writes: >One thing I've noticed about Kermit (using 9(40)) is that the transfer >rate seems very slow. I'm running a 9600 baud direct connect to a XENIX >box, and kermit reports the effective baud rate for file transfers at >about 1200. Is there any way to get this speed up, or is this just something >I have to live with? >-- > > James Moore > jamesm@sco.com Yes, unfortunately, even though the title is very froggy, Mac Kermit is a bit of a dog. It does terminal emulation (vt100) very well, but the througput of kermit file transfers is pretty pathetic. I've tried Microphone (a mild improvment) and VersatermPro (hang onto your hat cos this puppy flies) and have settled on VersaTerm Pro for any kermit transactions.. some rough benchmarks from memory (:-)).. 80K file download, with 1K block transfer selected. MacKermit = 10 + minutes VersaTerm = 2 minutes VersaTerm is sort of spendy, but if speed is money to you, it's worth the dough. Stu. __Paths to my door:_______________________ microsoft!stuartb@beaver.cs.washington.edu - Usual disclaimer, that all microsoft!stuartb@uw-beaver.arpa - the above is pure fantasy microsoft!stuartb@uunet.UU.NET - and Microsoft only [DE01HB]stuartb@DASNET# {from AppleLink} - gave me the Mountain Dew stuartb@microsoft.uucp {well connected} - to dream it all in a D2012 {@applelink.apple.com - shared acct} - caffeine haze :-) __________________________________________________________________________
jnh@ecemwl.ncsu.edu (Joseph N. Hall) (07/01/89)
In article <6197@microsoft.UUCP> stuartb@microsoft.UUCP (Stuart Burden) writes: >In article <3769@viscous.sco.COM> jamesm@sco.COM (James M. Moore) writes: >>One thing I've noticed about Kermit (using 9(40)) is that the transfer >>rate seems very slow. I'm running a 9600 baud direct connect to a XENIX >>box, and kermit reports the effective baud rate for file transfers at >>about 1200. Is there any way to get this speed up, or is this just something >>I have to live with? >Yes, unfortunately, even though the title is very froggy, Mac Kermit is >a bit of a dog. It does terminal emulation (vt100) very well, but the >througput of kermit file transfers is pretty pathetic. > Well, you can PAY for a program that Kermits faster, but why bother. If you're only transferring text files (I've never transferred anything that wasn't), then you can just TYPE or 'cat' files remotely and capture them to a text file. 9600 baud throughput (Mac Kermit DOES echo text FAST, unlike many other terminal programs), no problems. Sure you might get an occasional error, but I never have, and my attitude is that if it's just a text file, a garbled letter won't make any difference, and if it's a BinHexed file I'll know when it gets decoded. I suppose if it was numerical data or something then you might take some extra precaution, but ... Anyway, use Kermit for 2400 baud phone modem transfers ... but try just capturing the text if you've got a 'safe' connection. Works for me!
sbb@esquire.UUCP (Stephen B. Baumgarten) (07/05/89)
In article <6197@microsoft.UUCP> stuartb@microsoft.UUCP (Stuart Burden) writes: >Yes, unfortunately, even though the title is very froggy, Mac Kermit is >a bit of a dog. It does terminal emulation (vt100) very well, but the >througput of kermit file transfers is pretty pathetic. > >I've tried Microphone (a mild improvment) and VersatermPro (hang onto >your hat cos this puppy flies) and have settled on VersaTerm Pro for >any kermit transactions.. some rough benchmarks from memory (:-)).. > > 80K file download, with 1K block transfer selected. > > MacKermit = 10 + minutes > VersaTerm = 2 minutes > >VersaTerm is sort of spendy, but if speed is money to you, it's worth the >dough. Plain old VersaTerm is also very speedy and does everything that VersaTerm-PRO does (including the keyboard remapper) except for the extensive Tek emulation (it does do Tek emulation, it just doesn't give you all the bells and whistles). It also costs a lot less. Part of the reason VT is so much faster is that it can use extended length packets (e.g., 1K) and you can tell it not to do "quoting" for binary transfers if you have an 8 bit line (Kermit normally assumes a 7 bit line and "quotes" 8 bit characters, but the protocol allows for true 8 bit transfers that go almost as fast as YMODEM). VT 4.0 also supports Kermit server mode, which makes many kinds of file transfers more convenient. I'm not sure how much 4.0 is going for, but 3.2 only cost me $79 mailorder. It's a great value for the money. (Standard disclaimers apply: I'm just a happy customer). -- Steve Baumgarten | "New York... when civilization falls apart, Davis Polk & Wardwell | remember, we were way ahead of you." cmcl2!esquire!sbb | esquire!sbb@cmcl2.nyu.edu | - David Letterman