greggt@VAX1.CC.UAKRON.EDU (Gregg Thompson) (12/13/88)
To get sz to work with my dsz on my PC, I had to invoke sz with the -o option (16bit CRC). On the PC end I just type dsz pa5000 rz -y Now how does one get rz and sz on Unixand dsz sz & rz to work at 1024 blocks?? On bulliten boards I can upload and download at 1024 blocks just using standard commands with dsz (dsz rz and dsz sz), but when it comes to the Unix system it doesn't send or receive at 1024 characters a block!?!?! Ideas??? -- To live is to die, to die is to live forever; GRegg Thompson Where will you spend eternity? greggt@vax1.cc.uakron.edu
bobmon@iuvax.cs.indiana.edu (RAMontante) (12/13/88)
UAKRON.EDU> greggt@VAX1.CC.UAKRON.EDU (Gregg Thompson) writes: > > Now how does one get rz and sz on Unixand dsz sz & rz to work at >1024 blocks?? On bulliten boards I can upload and download at 1024 blocks By coincidence, I was looking at the man page just a few minutes ago... the (Unix-side) parameter L <blocksize> should do it. Note that this is a capital L, lowercase does something else. sz -L 1024 filename
julian@uhccux.uhcc.hawaii.edu (Julian Cowley) (01/03/89)
In article <54@VAX1.CC.UAKRON.EDU> Gregg Thompson writes: > Now how does one get rz and sz on Unixand dsz sz & rz to work at >1024 blocks?? On bulliten boards I can upload and download at 1024 blocks >just using standard commands with dsz (dsz rz and dsz sz), but when it comes >to the Unix system it doesn't send or receive at 1024 characters a block!?!?! >Ideas??? Actually, the block size you are referring to is known as the subpacket size, because the subpacket may or may not elicit a response from the receiver, unlike an X/Ymodem block which always elicits a response. The subpacket size itself is determined solely by the sender, however, and is usually based on the line speed. According to the Zmodem documentation, which the sz and rz programs follow, the recommended sizes for optimum throughput are 256 bytes for below 2400 baud, 512 for 2400 baud, and 1024 for 4800 baud and above. In my experience, like yours, most bulletin boards send 1024 bytes at 1200 baud, and there is no way to set it otherwise in case you have a bad connection. The reason for this is that the particular implementors of the remote Zmodem made the interface overly simple (perhaps necessarily), so that people wouldn't be overwhelmed by the many features that Zmodem actually supports. Sorry for the technical response, but it is interesting to note that Zmodem can be more flexible than it seems at first glance. julian@uhccux.uhcc.hawaii.edu uunet!ucsd!nosc!uhccux!julian julian@uhccux.bitnet "People who aren't amused don't talk."
cs374326@umbc3.UMD.EDU (Peter Johansson) (01/03/89)
In article <2919@uhccux.uhcc.hawaii.edu> julian@uhccux.uhcc.hawaii.edu (Julian Cowley) writes: >In article <54@VAX1.CC.UAKRON.EDU> Gregg Thompson writes:i] >> Now how does one get rz and sz on Unixand dsz sz & rz to work at >>1024 blocks?? On bulliten boards I can upload and download at 1024 blocks >>just using standard commands with dsz (dsz rz and dsz sz), but when it comes >>to the Unix system it doesn't send or receive at 1024 characters a block!?!?! >>Ideas??? > >Actually, the block size you are referring to is known as the >subpacket size, because the subpacket may or may not elicit a >response from the receiver, unlike an X/Ymodem block which always >elicits a response. [ rest deleted ] I don't want to steer anyone in the wrong direction since I've never read the Zmodem manual, but the following have been my experiences. I am using the version of zmodem available from simtel-20 in the unix-c archives, (v1.36) compiled on a vax 11/785 running Ultrix 2.0-1, and it defaults to a packet size of 1024 bytes at 2400 baud. It is possible that your system has an older version of sz/rz (I seem to remember the packet size to baud rate ratio different on older versions) or that your copy was edited before it was compiled. It is also possible that your sz command is aliased to 'sz -L 512' or something similar (an environment variable set to '-L 512') to allow data to pass through your terminal server(s). But in the end, it really shouldn't matter all that much. Remember, the only disadvantage to a small packet size in Zmodem is the overhead (header, CRC, etc) for each packet, and you do not have to worry about inter-packet delays as you do with x- and y-modem. Unless, of course, you have a severely brain damaged server that requires ACK's (or whatever code zmodem uses (don't flame me to RTFM)) after each packet to keep the server happy. (I have to use sz -l 1024 -L 1024 <filename>, for example) BTW, a newer version of sz/rz compiled under VMS 4.7 on a VAX 8600 (I don't remember which version; I don't use it very much as the port to vms left it rather buggy) does indeed limit the packet size to 512 bytes at 2400 baud.
bobmon@iuvax.cs.indiana.edu (RAMontante) (01/04/89)
julian@uhccux.uhcc.hawaii.edu (Julian Cowley) writes: -In article <54@VAX1.CC.UAKRON.EDU> Gregg Thompson writes: -> Now how does one get rz and sz on Unixand dsz sz & rz to work at ->1024 blocks?? On bulliten boards I can upload and download at 1024 blocks ->just using standard commands with dsz (dsz rz and dsz sz), but when it comes ->to the Unix system it doesn't send or receive at 1024 characters a block!?!?! ->Ideas??? - -Actually, the block size you are referring to is known as the -subpacket size, because the subpacket may or may not elicit a -response from the receiver, unlike an X/Ymodem block which always -elicits a response. [ rest deleted ] Simtel20 has a 12/20/88 version of DSZ; the following excerpt from its documentation may shed some light on this issue: Recent update history: 12-20-88 A side effect of some optimizations to deal with PC Pursuit buffering problems caused 2400 bps transfers to use 512 byte subpackets unless explicitly overridden or a ZMODEM window size was specified. While this does not slow things down much, numerous questions from users who confuse ZMODEM subpacket length with XMODEM block length did slow things down. So, yet another version. Further fixes to the "estimate" command; it now works. A confusing "Carrier Lost" message has been changed to the standard "No Carrier Detect" message which is explained in DSZ.DOC. (Note: I believe that ZMODEM window size is specified with the -L flag.)
julian@uhccux.uhcc.hawaii.edu (Julian Cowley) (01/04/89)
In article <1516@umbc3.UMD.EDU> cs374326@umbc3.UMD.EDU (Peter Johansson) writes: >But in the end, it really shouldn't matter all that much. Remember, the >only disadvantage to a small packet size in Zmodem is the overhead (header, >CRC, etc) for each packet, and you do not have to worry about inter-packet >delays as you do with x- and y-modem. 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. The recommendations that were in the Zmodem manual that I read gave the figures that I quoted in my previous article, but as you pointed out, it looks as though they have changed, especially if you found them in a program such as sz. This could be because the the recommendations for adjusting the packet size during transmission are still evolving. I'll have to download the Zmodem documentation or the sz program from Simtel20 again to find out for sure. julian@uhccux.uhcc.hawaii.edu uunet!ucsd!nosc!uhccux!julian julian@uhccux.bitnet "People who aren't amused don't talk."
asickels@bonnie.ics.uci.edu (Alan Sickels) (01/07/89)
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.