dpbst3@unix.cis.pitt.edu (David P Brennan) (04/16/91)
In article <CB.91Apr15114358@tamarack12.timbuk> cb@tamarack12.timbuk (Chris Brewster) writes: > >There has been discussion here about what is the best PC communication program. >PC Magazine and PC World have both had round-up articles on the subject >recently. I can't remember all the conclusions, but, taking the two articles >together, it would appear that Crosstalk Mk IV is the program to get. Each [stuff deleted] I forget which mag said it (prob. PC Mag) but for my money ProComm Plus is still the best- and most user-friendly. It may not do all the fancy stuff the others do, but the learning curve is real short on this one. Dave Brennan UPitt SLIS dpbst3@unix.cis.pitt.edu
atk@tigger.Colorado.EDU (Alan T. Krantz) (04/16/91)
In article <115854@unix.cis.pitt.edu> dpbst3@unix.cis.pitt.edu (David P Brennan) writes: > >I forget which mag said it (prob. PC Mag) but for my money ProComm Plus is >still the best- and most user-friendly. It may not do all the fancy stuff >the others do, but the learning curve is real short on this one. > I can't imagine why anyone would be a telecommunication program. With so many of them in the public domain (much less the ease of writing your own) it would seem somewhat silly to plunk down $100 bucks for such a program as crosstalk. For starters - I'd suggest kermit - not the greatest user interface - but at least it's small, efficient, supports vt100 emulation and tektronic emulation.
vancleef@iastate.edu (Van Cleef Henry H) (04/21/91)
In article <CB.91Apr15114358@tamarack12.timbuk> cb@tamarack12.timbuk (Chris Brewster) writes: > >There has been discussion here about what is the best PC communication program. >PC Magazine and PC World have both had round-up articles on the subject >recently. I can't remember all the conclusions, but, taking the two articles >together, it would appear that Crosstalk Mk IV is the program to get. Each >magazine also gave its "recommended" sticker to one or two other programs. I've >forgotten a couple of them, but Smartcom Exec (from Hayes) was found to be the >fastest program over-all. This isn't particularly relevant if the limiting >factor is your modem speed, which it is if you're using a phone line. > >Christopher Brewster A while back I bought Crosstalk Mk IV. I dislike it intensely. Very difficult to walk around the menus, very difficult to configure, very difficult to use, requires that all sorts of stuff be in the same directory as you are running it from. Procomm 2.4.3 is Shareware and while it insists its control files be in the same directory you start from, it is fairly good. Procomm Plus is even better. Kermit is free, and does everything I want and need. There is a brand new version 3.10 for Pee Cee. The only thing against Kermit is that while the transfer is pretty reliable, the frog doesn't jump awfully high---X/Y/Zmodem are faster for most purposes. Speed? the COM port dictates the speed. Procomm has Kermit and a bunch of other protocols, everything you need, I think. --
c60b-1eq@e260-1a.berkeley.edu (Noam Mendelson) (04/21/91)
In article <1991Apr21.071509.13167@news.iastate.edu> vancleef@iastate.edu (Van Cleef Henry H) writes: >Kermit is free, and does everything I want and need. There >is a brand new version 3.10 for Pee Cee. The only thing >against Kermit is that while the transfer is pretty >reliable, the frog doesn't jump awfully high---X/Y/Zmodem >are faster for most purposes. Not necessarily. On clean lines, if you set the blocksize to 1K and the check to a 3-byte CRC, you'll get decent throughput (that of YModem). And, as a block protocol (as opposed to the streaming ZMODEM), it tends to be a lot more reliable under non-standard conditions. It's too bad that MS-Kermit doesn't support sliding windows yet. *sigh* -- +==========================================================================+ | Noam Mendelson ..!ucbvax!web!c60b-1eq | "I haven't lost my mind, | | c60b-1eq@web.Berkeley.EDU | it's backed up on tape | | University of California at Berkeley | somewhere." |
c60b-1eq@e260-1e.berkeley.edu (Noam Mendelson) (04/22/91)
In article <1991Apr21.085326.28167@agate.berkeley.edu> c60b-1eq@e260-1a.berkeley.edu (Noam Mendelson) writes: >It's too bad that MS-Kermit doesn't support sliding windows yet. *sigh* ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I stand corrected. MS-Kermit does support sliding windows. -- +==========================================================================+ | Noam Mendelson ..!ucbvax!web!c60b-1eq | "I haven't lost my mind, | | c60b-1eq@web.Berkeley.EDU | it's backed up on tape | | University of California at Berkeley | somewhere." |
neal@mnopltd.UUCP (04/24/91)
->Procomm 2.4.3 is Shareware and while it insists its control ->files be in the same directory you start from, it is fairly ->good. Procomm Plus is even better. Err.... can't you set the PROCOMM= variable to specify a fixed directory? ------------------------------------------------------------------------------ Neal Rhodes MNOP Ltd (404)- 972-5430 President Lilburn (atlanta) GA 30247 Fax: 978-4741 emory!mnopltd!neal gatech!emory!mnopltd!neal ------------------------------------------------------------------------------
silvert@cs.dal.ca (Bill Silvert) (04/24/91)
In article <203@mnopltd.UUCP> gatech!stiatl!mnopltd!neal writes: > >->Procomm 2.4.3 is Shareware and while it insists its control >->files be in the same directory you start from, it is fairly >->good. Procomm Plus is even better. > >Err.... can't you set the PROCOMM= variable to specify a fixed directory? Sure. I run ProComm from a batch file that sets PROCOMM= and then runs the binary. It works fine from any directory. By doing it this way I can keep configuration files in different directories and use separate batch files to run different configurations (different ports at different speeds, etc.). -- William Silvert, Habitat Ecology Division, Bedford Inst. of Oceanography P. O. Box 1006, Dartmouth, Nova Scotia, CANADA B2Y 4A2. Tel. (902)426-1577 UUCP=..!{uunet|watmath}!dalcs!biome!silvert BITNET=silvert%biome%dalcs@dalac InterNet=silvert%biome@cs.dal.ca
mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) (04/27/91)
In article <1991Apr21.085326.28167@agate.berkeley.edu> c60b-1eq@e260-1a.berkeley.edu (Noam Mendelson) writes: >In article <1991Apr21.071509.13167@news.iastate.edu> vancleef@iastate.edu (Van Cleef Henry H) writes: >> ... The only thing >>against Kermit is that while the transfer is pretty >>reliable, the frog doesn't jump awfully high---X/Y/Zmodem >>are faster for most purposes. >Not necessarily. On clean lines, if you set the blocksize to 1K and >the check to a 3-byte CRC, you'll get decent throughput (that of YModem). >And, as a block protocol (as opposed to the streaming ZMODEM), it tends >to be a lot more reliable under non-standard conditions. >It's too bad that MS-Kermit doesn't support sliding windows yet. *sigh* The comment concerning sliding window support is erroneous. MS-Kermit 3.10 does support sliding windows. In most cases, the problem is that the remote end does not support sliding windows. In file transfers through a 2400 baud modem link using 512 byte packets and 3 windows, an effective baud rate of 2510 to 2560 is typical transfer rate for text files. The effective baud rate decreases as you decrease the packet size; however, I haven't noticed any improvement in the effective baud rate as you increase the packet size from 512 bytes. The above data was obtained from a path that also involved a 7 bit rlogin link over an ethernet. Using "direct" connections over a broadband at 9600 and 19.2K the effective baud rate is around 9000 and 18K, respectively. The broadband has some problems with flow control and lost data at 19.2K. This environment demonstrates a "secondary" feature of the MS-Kermit windows op- tion--automatic down-sizing of the packet on detection of errors and restor- ation of the original packet size when error conditions have cleared. Merton Campbell Crockett
c60b-1eq@e260-1e.berkeley.edu (Noam Mendelson) (04/27/91)
In article <1991Apr27.031643.23049@wlbr.imsd.contel.com> mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes: > In file transfers through a 2400 baud >modem link using 512 byte packets and 3 windows, an effective baud rate of >2510 to 2560 is typical transfer rate for text files. The effective baud >rate decreases as you decrease the packet size; however, I haven't noticed >any improvement in the effective baud rate as you increase the packet size >from 512 bytes. The 2510-2560 bps figure for text data is due to Kermit's RLE compression, _not_ due to windowing. It's fairly difficult to get around the 240 cps maximum for 2400 bps transfers. Some protocols like SUPERK establish a synchronous connection with the other end and eliminate the start/stop bit bottleneck (MNP-3 and above do this too, but at a hardware level). This allows for a theoretical 300 cps transfer rate at 2400 bps. However, this method is very error-prone, and SUPERK is the only file transfer protocol that I know of which utilizes it. If you want to get unbiased results, and you can't turn off Kermit's compression, try running some text data through crypt(1) and then sending. Also, if you have clean lines, I would recommend that you set the packet size as high as possible, especially at higher speeds (to minimize the delays caused by ACKs). At 2400 bps, 512 byte packets are OK; at 9600, I would definitely suggest 1K or greater. -- +==========================================================================+ | Noam Mendelson ..!ucbvax!web!c60b-1eq | "I haven't lost my mind, | | c60b-1eq@web.Berkeley.EDU | it's backed up on tape | | University of California at Berkeley | somewhere." |
mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) (04/27/91)
In article <1991Apr27.053539.10761@agate.berkeley.edu> c60b-1eq@e260-1e.berkeley.edu (Noam Mendelson) writes: >In article <1991Apr27.031643.23049@wlbr.imsd.contel.com> mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes: >> In file transfers through a 2400 baud >>modem link using 512 byte packets and 3 windows, an effective baud rate of >>2510 to 2560 is typical transfer rate for text files. The effective baud >>rate decreases as you decrease the packet size; however, I haven't noticed >>any improvement in the effective baud rate as you increase the packet size >>from 512 bytes. > >The 2510-2560 bps figure for text data is due to Kermit's RLE compression, >_not_ due to windowing. It's fairly difficult to get around the 240 cps >maximum for 2400 bps transfers. Sorry about that. I should have indicated that setting the windows to 1--ie disabling the sliding windows option--yields an effective transfer rate in the 2280-2340 bps range for text data. Kermit's automatic compression was involved in the transfers; however, the effective transfer rate was not due to the effects of compression but the effects of sliding windows. Probably should have also noted that MS-Kermit 3.10 now provides an automatic detection and notification of a 7 bit data link in the path between the local and remote system. When a 7 bit data link is detected and the file type is set to binary, the binary data is encoded to traverse the 7 bit data link segment. A useful feature when you forget the -8 switch to rlogin. Another tacit assumption in this discussion is that the remote station is using C-Kermit 4E, 4F, 5A, or equivalent version of Kermit. Also, to be noted is that the remote stations run 2.11 BSD, 4.3 BSD, and VMS 5.1 oper- ating systems. (The remote station running C-Kermit 4E is a 4.3 BSD system which is reached over a transcontinental 56Kb X.25 packet switched link. I tried it a couple of times but as it doesn't support windows and I had difficulty figuring out the link latency, the transfer would typically be aborted due to an excessive delay at some point.) Another remote station running System V R3 something or another and using an earlier version of C-Kermit goes Tango Uniform when it finds the window option in the negotiation packet. Of the various systems I use only the VMS system has C-Kermit 5A which has support for windows. It also requires an rlogin connection from my home system. At 9600 and 19.2K, the 1024 packet size improves performance when the remote station does not use windows or they are disabled over that obtained from using 512 byte packets. In my experience the difference is nominal when using sliding windows. Performance may decrease with larger packets due to resource limitations on the remote station. Merton Campbell Crockett