price@uclapp.physics.ucla.edu (John Price) (06/01/91)
Hi all:
I have a question about just how ZTerm does file transfers. I transfer
files from a VAX running VMS (rz 3.01, sz 3.03) to either a Plus (at 2400
bps) or a IIcx (at 19200 bps) and back. Transfers *from* the VAX work
great - I get 237 cps (!) to the Plus, and about 1050 cps to the IIcx. I
don't expect to be able to improve either speed by too much - certainly not
the Plus...
However, going from either Mac to the VAX is painful. I keep getting ZRPOS
errors. The fastest transfer I can get on the IIcx is about 500 cps. I
tried playing with the Zmodem parameters a bit - I noticed that changing
the "subpacket length" didn't have much effect, but changing the "Window
limit" did seem to help.
Initially, there was no window limit - the box was empty. Not having the
slightest idea what I was doing, I put 100 there and tried the transfer
again. This time, it appeared as if the program wasn't trying to send as
much data at one time as it had before - the "bytes sent" field updated
much more quickly than before. When I looked at the window limit again, to
try a different number, I saw that the program had automatically changed it
to 256.
OK, I can deal with that. It wants multiples of 256. I have no idea why,
but now I at least have a handle on how to affect the program's operation.
I found that the larger I made this number, the faster I was able to
transfer data. This effect seems to flatten out with a window limit of
about 4096 (it's currently set to 16384).
Now, my questions to Dave Alverson (or anyone who has more of a clue about
this than I do - that shouldn't cut too many people out :) are the
following:
1: What is the "subpacket length"?
2: What is the "window limit"?
3: How can I optimize the transfer speed *to* the VAX without
affecting the transfer speed *from* the VAX?
4: (to Dave Alverson specifically) Could you put at least a cursory
description of this in the docs for the next version?
Thanks a lot in advance!
John Price * * * * price@uclapp.physics.ucla.edu
Where there is no solution, there is no problem.dplatt@ntg.com (Dave Platt) (06/02/91)
In article <009496DA.C7E09C00@uclapp.physics.ucla.edu> price@uclapp.physics.ucla.edu (John Price) writes: >OK, I can deal with that. It wants multiples of 256. I have no idea why, >but now I at least have a handle on how to affect the program's operation. >I found that the larger I made this number, the faster I was able to >transfer data. This effect seems to flatten out with a window limit of >about 4096 (it's currently set to 16384). I have a hunch that any value over 4096 is treated as a 4096-byte limit. I use a 2048-byte limit when uploading and downloading via a V.32 modem at 9600 bps... this seems optimal for my configuration. >Now, my questions to Dave Alverson (or anyone who has more of a clue about >this than I do - that shouldn't cut too many people out :) are the >following: > > 1: What is the "subpacket length"? The ZMODEM protocol divides your data into packets, each one of which contains a certain number of bytes of data. Each packet has a header, and a trailer which includes a CRC code to detect errors. If the receiver of a ZMODEM transmission detects a CRC error in a packet, it tells the sender to back up and retransmit data from where that packet started (in the original file)... this is the "ZRPOS" message you're seeing. Any additional packets which were "in transit" are discarded by the receiver. If you have a noise-free connection, it helps to use large packet sizes, because there's a fixed amount of overhead in each packet. If you have a noise-prone connection, smaller packets tend to be better... there will be less chance that any particular packet will be corrupted by line noise, and the protocol will spend a bit less time "backing up" and retransmitting (and discarding large packets which were "in transit" at the time of the error). > 2: What is the "window limit"? Normally, ZMODEM operates in a "streaming" mode... the sender transmits data as fast as possible, the receiver swallows it as fast as it can, and the receiver sends back signals only when data isn't received properly. This mode has the least overhead, and the fastest transmission rate, _if_ the receiver is able to keep up with the sender. If the receiver _cannot_ keep up with the sender, the sender will occasionally "over-run" the receiver's buffers; data will be lost, and the receiver will have to tell the sender to back up and retransmit. A convenient way to avoid this is to use the "sliding window" mode... controlled by the window-limit field in ZTerm, and by the "-w" option in the Unix "sz" program. In this mode, the sender assumes that there is a "window" of buffer space in the receiving program which it is not allowed to over-fill. The sender transmits four packets, each of which contains (windowsize/4) bytes of data; attached to each packet is a code which means "Please acknowledge this when you get it." The receiver sends back an acknowledgement as soon as it has decoded a packet and written it to disk... this "opens the window" for the sender to transmit another packet. In almost all cases, the receiver will have sent back the acknowledgement for packet #1 before the sender has finished transmitting packet #4, and thus the transmitter can go ahead and send #5 immediately. If the receiver gets bogged down for any reason, the sender will not receive ACKs promptly, and will simply wait for the ACKs before it sends any more data. With this scheme, there are never more than "windowsize" bytes of data "in transit" at any one time. I almost always use sliding-window mode with ZMODEM. It adds only a very slight amount of overhead, and its end-to-end flow control makes uploading and downloading more reliable. > 3: How can I optimize the transfer speed *to* the VAX without > affecting the transfer speed *from* the VAX? The packet-size and window-limit parameters are set at the transmitting end, not at the receiving end. So, if you tweak them in ZTerm's configuration, they'll affect uploads to the VAX, but will not affect downloads from the VAX. You can use equivalent options to "sz" if you want to add sliding-window mode to your downloads. >Thanks a lot in advance! You're welcome! -- Dave Platt VOICE: (415) 813-8917 Domain: dplatt@ntg.com UUCP: ...apple!ntg!dplatt USNAIL: New Technologies Group Inc. 2468 Embarcardero Way, Palo Alto CA 94303
ian@umiami.ir.miami.edu (06/05/91)
In article <009496DA.C7E09C00@uclapp.physics.ucla.edu>, price@uclapp.physics.ucla.edu (John Price) writes: > Hi all: > > I have a question about just how ZTerm does file transfers. I transfer > files from a VAX running VMS (rz 3.01, sz 3.03) to either a Plus (at 2400 > bps) or a IIcx (at 19200 bps) and back. Transfers *from* the VAX work > great - I get 237 cps (!) to the Plus, and about 1050 cps to the IIcx. I > don't expect to be able to improve either speed by too much - certainly not > the Plus... > > However, going from either Mac to the VAX is painful. I keep getting ZRPOS > errors. The fastest transfer I can get on the IIcx is about 500 cps. I > tried playing with the Zmodem parameters a bit - I noticed that changing > the "subpacket length" didn't have much effect, but changing the "Window > limit" did seem to help. > > Initially, there was no window limit - the box was empty. Not having the > slightest idea what I was doing, I put 100 there and tried the transfer > again. This time, it appeared as if the program wasn't trying to send as > much data at one time as it had before - the "bytes sent" field updated > much more quickly than before. When I looked at the window limit again, to > try a different number, I saw that the program had automatically changed it > to 256. > > OK, I can deal with that. It wants multiples of 256. I have no idea why, > but now I at least have a handle on how to affect the program's operation. > I found that the larger I made this number, the faster I was able to > transfer data. This effect seems to flatten out with a window limit of > about 4096 (it's currently set to 16384). > > Now, my questions to Dave Alverson (or anyone who has more of a clue about > this than I do - that shouldn't cut too many people out :) are the > following: > > 1: What is the "subpacket length"? > 2: What is the "window limit"? > 3: How can I optimize the transfer speed *to* the VAX without > affecting the transfer speed *from* the VAX? > 4: (to Dave Alverson specifically) Could you put at least a cursory > description of this in the docs for the next version? > > Thanks a lot in advance! > > John Price * * * * price@uclapp.physics.ucla.edu > Where there is no solution, there is no problem. Someone probably already said this... I had the same problem here...Check to see whether the VAX end of the connection is 8bit..I believe Z-Term will only transfer to an 8 bit connection.. Course I could be wrong..:) -- Scruffy Ian Sullivan ******************************************************************************* **ian@umbio.med.miami.edu % "God is dead"- Nietsche ** **ian@umiami.ir.miami.edu % "Nietsche is dead"- God ** **ian@umiami.bitnet % "Nietsche is God"- The Dead ** ** % ** **UUU UMUMMM MMMMMM % "Skate to Kill..Kill to Skate" ** **UUU UMU MMM MMM MMM % ** **uUU UMU MMM MMM MMM % "Life's been good to me so far..." -J.W. ** **UUUUUUUUMUof MMMMM MMM % "Give it a while." -Me. ** ******************************************************************************* Damn, Underwater Basket Weaving 302 is filled, well there goes my summer!