boneill@hawk.ulowell.edu (SoftXc Coordinator) (05/05/88)
Now that I am able to use DSZ for downloads without problem, and it is
finally working faster than Kermit, I have a new problem. In reversing the
works and doing an upload, I have not been able to get DSZ to get farther
than 15360 bytes, before it goes into and endless series of ERROR RECOVERY
messages. This happened on both 0414 and 0423 versions, using 1.44 and 2.02
versions of rz on the host end. This could be another Sytek Broadband
problem, but really have no way of knowing otherwise right now.
Any help would be appreciated.
============================================================================
Brian O'Neill, MS-DOS Software Exchange Coordinator
ArpaNet: boneill@hawk.ulowell.edu
UUCP : {(backbones),harvard,rutgers,et. al.}!ulowell!hawk!boneilldow@wjh12.harvard.edu (Dominik Wujastyk) (05/05/88)
In article <6793@swan.ulowell.edu> boneill@hawk.ulowell.edu (SoftXc Coordinator) writes: >Now that I am able to use DSZ for downloads without problem, and it is >finally working faster than Kermit, I have a new problem. In reversing the >works and doing an upload, I have not been able to get DSZ to get farther >than 15360 bytes, before it goes into and endless series of ERROR RECOVERY >messages. This happened on both 0414 and 0423 versions, using 1.44 and 2.02 >versions of rz on the host end. This could be another Sytek Broadband >problem, but really have no way of knowing otherwise right now. > I too have had trouble with DSZ uploads. I have 0423 on my PC/AT, and I don't know which version is working on the Unix host, but a fairly recent one (a couple of months old). I can download fine, but cannot upload at all. I get the same ERROR messages as mentioned above, but straight away, not after 15k. Any suggestions (apart from fallback to good ol' Kermit)? Dominik -- bitnet: user DOW on the bitnet node HARVUNXW arpanet: dow@wjh12.harvard.edu csnet: dow@wjh12.harvard.edu uucp: ...!ihnp4!wjh12!dow
adonis@tahoe.unr.edu (Paul Graham) (05/08/88)
In article <209@wjh12.harvard.edu> dow@wjh12.UUCP (Dominik Wujastyk) writes: }In article <6793@swan.ulowell.edu> boneill@hawk.ulowell.edu (SoftXc Coordinator) writes: }>Now that I am able to use DSZ for downloads without problem, and it is }>finally working faster than Kermit, I have a new problem. In reversing the }>works and doing an upload, I have not been able to get DSZ to get farther }>than 15360 bytes, before it goes into and endless series of ERROR RECOVERY }>messages. This happened on both 0414 and 0423 versions, using 1.44 and 2.02 }>versions of rz on the host end. This could be another Sytek Broadband }>problem, but really have no way of knowing otherwise right now. }> } }I too have had trouble with DSZ uploads. I have 0423 on my PC/AT, and }I don't know which version is working on the Unix host, but a fairly recent }one (a couple of months old). I can download fine, but cannot upload at }all. I get the same ERROR messages as mentioned above, but straight away, }not after 15k. More than likely, the problem is buffering in the network. Zmodem is a streaming protocol, so it does not wait for a response after each packet is sent. This results in the netwroks buffers becoming overridden fairly quickly. (I would think that the reason it takes longer in Boneill's case is that his network has larger buffers.) In order to force Zmodem to stop and wait for a response, one must set the numeric parameter "w" to 1024 or so (depending on the network). This tells Zmodem to stop and wait every 256 bytes. In order to set it to 1024 (as an example) is to include in the command line (before the "sz" or "rz", and after the speed and port settings) "z pw1024". Experiment with this number. You want the largest number that will allow transfers. This will be different for every network. I quote from the Zcomm manual in regard to this parameter: w If non 0, restrict the ZMODEM transmitted window to the specified number of bytes. Setting this parameter to N requests acknowledgements from the receiver every N/4 characters. Pro-YAM [Zcomm and DSZ too (my insertion)] then waits for acknowledgements from the receiver whenever it has sent N more characters thean it has received acknowledgements for. This parameter is uesful with networks with defective flow control, and with networks that store an excessive number of characters in transit. Another parameter that might be useful is the "l" parameter, described in the following: l If non zero, forces ZMODEM to close a frame and wait for an ACK after each # bytes (default 0). The frame length may be adjusted to prevent buffer overflow in data PBX systems. Using one of these two parameters has given me error free transfers in both directions through a Sytek network. This is particularly astonishing since the Zmodem program on the UNIX end thinks that we are at 9600 baud, when actually, after going through the network, things are at 1200 baud (ugh!). Hope this help. -- ----------------------------------------------------------------------------- There are more important things to be | Derrick Hamner than responsible. | {backbone}!tahoe.unr.edu!adonis