Xref: utzoo comp.binaries.ibm.pc.d:1690 comp.sys.ibm.pc:22887 Path: utzoo!utgpu!attcan!uunet!lll-winken!ames!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!sm.unisys.com!oberon!orion.cf.uci.edu!paris.ics.uci.edu!bonnie.ics.uci.edu!asickels From: asickels@bonnie.ics.uci.edu (Alan Sickels) Newsgroups: comp.binaries.ibm.pc.d,comp.sys.ibm.pc Subject: Re: DSZ rz & sz Message-ID: <3290@paris.ics.uci.edu> Date: 6 Jan 89 21:53:12 GMT References: <54@VAX1.CC.UAKRON.EDU> <2919@uhccux.uhcc.hawaii.edu> <1516@umbc3.UMD.EDU> <2927@uhccux.uhcc.hawaii.edu> Sender: news@paris.ics.uci.edu Reply-To: Alan Sickels Distribution: na Organization: University of California, Irvine - Dept of ICS Lines: 59 In article <2927@uhccux.uhcc.hawaii.edu> julian@uhccux.uhcc.hawaii.edu (Julian Cowley) writes: >That's true, as long as you have a relatively error-free line, >but if you have a bad telephone line, then it makes a lot of >difference. Just as with X/Ymodem, the sender has to retransmit >an entire block (or subpacket) if the receiver says it didn't >receive it correctly the first time. The larger the block, >then, the longer it takes for the retransmission. At 1200 baud, >a 1024 byte block takes at least a couple of seconds, less >overhead. Therefore, the real trick is finding the block size >that permits best thoughput, and is usually dependent on the >line speed and error level. Do you send large blocks that has >less overhead but longer retransmission time, or do you send >small blocks that have more overhead but shorter retransmission >time? Higher line speeds mean that larger blocks can be used >because they take less time to retransmit. Conversely, higher >error rates mean that larger blocks waste time because it will >mean more retransmissions. Quoted from the ZMODEM protocol description in the Professional-YAM manual by Omen Technology, Inc. (the same people who bring you DSZ): [Begin Quote] The ZMODEM _subpacket length_ and the ZMODEM _frame length_ deserve special mention. People tend to confuse these with the familiar 128 and 1024 byte block length used in XMODEM transfers. When ZMODEM frame length of 0 is specified (the default), a single frame will span the entire file if there are no errors. This is the main source of ZMODEM's reputation for fast transfers. Setting the ZMODEM frame length to a number between 64 and 16384 restricts the frame length to that value. At the end of each frame, the sender stops sending and waits for an acknowledgement from the receiver. When set, the ZMODEM frame length corresponds in function to the 128 or 1024 byte block length of XMODEM based protocols. Each ZMODEM frame consists of one or more _subpackets_ of 32 to 1024 bytes. Since the subpackets within a frame are sent without pause, a short subpacket length does not exact the terrible throughput penalty associated with short XMODEM and Kermit blocks. In the absence of transmission errors, a 256 byte subpacket length has about two per cent more overhead than a 1024 byte subpacket length. However, the longer subpacket length does increase error recovery time. Professional-YAM dynamically adjusts the ZMODEM subpacket length on the basis of transmission speed and observed error rate. If you know what the error rate on a particualr call will be before starting a ZMODEM file transfer, setting the L numeric parameter will provide a small but noticable improvement in performance, with 1024 best for clean lines and smaller numbers better for noisy lines. [End Quote] From my own personal experience of when I hooked up two computers with a null modem and communicated at 19,200 I can attest to the fact that DSZ also will dynamically adjust. We would get a line hit and the subpacket length would drop to 128 and build itself back up to 1024 if it didn't get any hits.