[comp.sys.ibm.pc.misc] Comm programs, Crosstalk Mk IV

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