Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!deimos!eecea!gordon
From: gordon@eecea.eece.ksu.edu (Dwight Gordon)
Newsgroups: comp.sys.ibm.pc
Subject: Re: XMODEM,YMODEM,ZMODEM,KERMIT Which is best and why?
Keywords: ZMODEM, KERMIT
Message-ID: <920@eecea.eece.ksu.edu>
Date: 2 Jan 90 01:34:28 GMT
References: <32428@news.Think.COM> <919@eecea.eece.ksu.edu> <9457@spool.cs.wisc.edu>
Reply-To: gordon@eecea.UUCP (Dwight Gordon,DU280,5600,)
Organization: Kansas State University, Manhattan
Lines: 51

In article <9457@spool.cs.wisc.edu> thaler@shorty.cs.wisc.edu (Maurice Thaler) writes:
>In article <919@eecea.eece.ksu.edu> gordon@eecea.UUCP (Dwight W. Gordon) writes:
>>ZMODEM -
>>3.  Not as robust as KERMIT.
>>    a.  noisy environments (bad phone connections) causes troubles
>>    b.  multitasking (DesqView) a graphics (high cpu overhead) application
>>        in another window tends to cause retries/packet failures (yes, I
>>        know that there must be a way to tune the DesqView parameters so
>>        that this doesn't happen.  I haven't found it!)
>
>Sorry Dwight, I don't buy this one. ZMODEM is very robust. 32bit-crc
>gives your virtually identical files including date and time stamping.
>Also, as the baud rate goes up the speed difference between ZMODEM and
>Kermit widens. I use a US Robotics Dual Standard modem and regularly get
>>1600bps using ZMODEM . Kermit could never do that, not even
>SuperKermit.  If you are having problems with DesqView with DSZ or
>ZCOMM, I would suggest that it could be  either EMS memory management
>and/or a less than well behaved disk cache that causes intrupt latecency
>problems (well documented in DSZ.DOC) or a less than wonderful UART.
>I switched to the NS16550an UART as recommended by Forsberg in the
>DSZ.DOC (about a  $20 mod) and it cleared up all high speed/multitasking
>problems.

  EMS is QEMM.  It's interrupt latency all right.  I admit the UART my
strange (a custom VLSI for both UART channels - no $20 fix, board
replacement time for the FIFO uart).  The problem comes with graphic
foreground tasks and telecommunications in the background.  ZMODEM
sees troubles and decreases the packet size.  The unix box on the other
end (3b15) suddenly gets "bogged down" with packets that have gotten
as small as 32 bytes!  (32 bits of CRC/32 Bytes of data => ~11%
overhead).  My point is that the graphic activities that generally
cause this decrease in packet size are of a relatively short duration.
Kermit doesn't change the packet size (at least my version doesn't).
It drops packets just as ZMODEM does.  However, with a "large" file,
it more than catches up with its 1K packets (vs. the 32byte packets I 
end up with under ZMODEM).
  Note:  I've tried "Tuning" my DesqView and haven't come up with a
solution that both 1) doesn't drop packages in the background, and
2) leaves me enough time-slices in the foreground so that I still
feel as if I'm running a 25MHz '386!

- Dwight -
P.S. I knew that my original posting was an invitation for flames.
I was hoping for some constructive suggestions to fix the problem.
I prefer ZMODEM.  Has anybody out there seen a "cheap" 2S/1P card
with the FIFO uart chips on it?
-- 
Dwight W. Gordon, Ph.D.  |   913-532-5600    |   gordon@eecea.eece.ksu.edu
Electrical & Computer Engineering Department |     dwgordon@ksuvm.bitnet
Kansas State University - Durland Hall       | rutgers!ksuvax1!eecea!gordon
Manhattan, KS 66506      | {pyramid,ucsd}!ncr-sd!ncrwic!ksuvax1!eecea!gordon