mcdonald@fornax.UUCP (Ken Mcdonald) (10/13/90)
I've started using Zterm to transfer files over the phone line from UNIX to my Mac, but have encountered a real problem--if there is even one error during the transmission, Zterm will then find an error on each successive block (effectively halving the transmission rate), and will usually garble the data anyways. Any suggestions to cure this behavious? Thanks, Ken McDonald PS please e-mail responses to mcdonald@cs.sfu.ca. This newgroup is just too high-volume for me to keep up with it.
cmm1@cunixa.cc.columbia.edu (Christopher M Mauritz) (10/14/90)
In article <1380@fornax.UUCP> mcdonald@fornax.UUCP (Ken Mcdonald) writes: >I've started using Zterm to transfer files over the phone line from >UNIX to my Mac, but have encountered a real problem--if there is >even one error during the transmission, Zterm will then find an >error on each successive block (effectively halving the transmission >rate), and will usually garble the data anyways. Any suggestions to >cure this behavious? Same thing happened to me. I just stopped using the damn program. I'll give it another try when the author updates it and kill some of the more annoying bugs. I have no problem shelling out shareware fees, but I demand a workable program in return. Zterm also seems to crash my MacIIcx on a far more regular basis than any other program (except Boomerang). Cheers, Chris ------------------------------+--------------------------- Chris Mauritz |D{r det finns en |l, finns cmm1@cunixa.cc.columbia.edu |det en plan! (c)All rights reserved. | Send flames to /dev/null | ------------------------------+---------------------------
252u3129@fergvax.unl.edu (Mike Gleason) (10/15/90)
I've got the same situation, only it works for me. I have a direct connection to my unix host at 19.2 kbaud (for a 1200 baud modem user, this sure is a shock! I just got a copy of the 6.0.5 System Tools disk off apple.com, and it only took me 7 minutes! But then again, that'll be nothing 10 years from now when everyone will have 64.4 kbaud ISDN). What I have to do to get it to work, is tell my unix host to turn on escape control characters. Of course that will bog down your speed a little, but it sure beats sending text dumps of .hqx files like I used to. Try something like this: sz -eo <files>. _____________________________________________________________________________ * Mike Gleason 252u3129@fergvax.unl.edu * "Don't you f*ckin' look at me!" -- D. Hopper cosc006@unlcdc2.unl.edu
ho@hoss.unl.edu (Tiny Bubbles...) (10/15/90)
In <1990Oct15.092858.28019@hoss.unl.edu> 252u3129@fergvax.unl.edu (Mike Gleason) writes: >What I have to do to get it to work, is tell my unix host to turn on >escape control characters. Of course that will bog down your speed a >little, but it sure beats sending text dumps of .hqx files like I used >to. Try something like this: sz -eo <files>. As an aside, this often is caused not by the communications packages, but by flaky network protocols. Zmodem expects a full 8-bit path, and many telnet daemons routinely translate CR+NUL pairs into plain CR's, regardless of the settings of any network parameters, including XmitBinary and Transparent. Sometimes the network is at fault, other times the host telnet daemon is at fault. Some versions of Zmodem allow you to quote specified characters rather than all control codes, which would allow nearly-optimum transfer rates (for this special case, you'd just quote NULs and CR's.) Most Unix versions of Zmodem do NOT offer this, because Chuck Forsberg, Zmodem author, decided to make that part of his protocol proprietary. -- ... Michael Ho, University of Nebraska Internet: ho@hoss.unl.edu | "Mine... is the last voice that you will ever hear." -- ... Michael Ho, University of Nebraska Internet: ho@hoss.unl.edu | "Mine... is the last voice that you will ever hear."
dplatt@coherent.com (Dave Platt) (10/16/90)
In article <1990Oct14.150133.19303@cunixf.cc.columbia.edu> cmm1@cunixa.cc.columbia.edu (Christopher M Mauritz) writes: > In article <1380@fornax.UUCP> mcdonald@fornax.UUCP (Ken Mcdonald) writes: > >I've started using Zterm to transfer files over the phone line from > >UNIX to my Mac, but have encountered a real problem--if there is > >even one error during the transmission, Zterm will then find an > >error on each successive block (effectively halving the transmission > >rate), and will usually garble the data anyways. Any suggestions to > >cure this behavious? > > Same thing happened to me. I just stopped using the damn program. I believe I've pinned down one cause for some of the excessive error thrashing when using ZTerm and Unix. It's not hard to work around it. When you're running sz on a Unix system, it starts writing output to the Unix system's serial port as fast as it can. Most Unix machines support a substantial amount of serial-port output buffering... 4k or even more... and sz will be able to push this much data into the buffers before it is forced to "go to sleep" by an output-buffer-full condition. Things can be even worse if you're dialed into Unix via a TIP or packet-switch of some sort... there's usually some output-buffer memory in the TIP/switch, and quite a bit of output buffering occurs in the Unix system's TCP/IP handlers as well. If ZTerm detects an error in an incoming packet, it will transmit a "Hey, back up to byte NNNN and try again" response (a ZRPOS packet). It will then discard data until it sees a packet which has an offset of NNNN. If it doesn't see a suitable packet within some number of seconds, it will assume that its ZRPOS was lost, and it will transmit another. This scheme works well as long as the ZMODEM sender is able to receive and act upon the ZRPOS fairly promptly, and can deliver the retransmitted data to the receiver within the timeout interval. If there's a long "pipeline" between the sender and receiver, this scheme can break down... retransmitted data may not make it to ZTerm before its ZRPOS timer expires, and this will result in another ZRPOS being sent. The same data ends up being transmitted repeatedly. Eventually, sz gets the idea that the transmission line is noisy, and starts sending smaller packets... this sometimes clears the cloggage. There's a fairly easy (but poorly documented) way to work around this problem. Most versions of sz support a "sliding window" mode of operation, invoked by the "-w" option. In this mode, sz will transmit four packets, whose total size does not exceed the "window size" specified by the -w option. Each packet will have a "please acknowledge" flag attached; ZTerm sends back an acknowledgement after successfully decoding each packet. sz waits for the first acknowledgement to come back before sending the fifth packet, waits for the second ack before sending the sixth packet, and so forth. This limits the amount of data "in the pipeline" to a sane value, and speeds up error recovery somewhat. Sliding-window mode has a somewhat higher overhead than streaming mode, due to the shorter packets and the need for an acknowledgement after each one. The difference is small... a couple of percent, in most cases... and the transmittion pipeline usually remains 100% busy, with no pauses between packets. Sliding-window mode also eliminates some nasty flow-control problems which can occur when you're working with multi-speed modems and network connections. To download a binary file, I usually use the command sz -b -w 2048 foo.bin Over a 2400-bps line, this delivers one 512-byte packet every couple of seconds. The total amount of data "in the pipeline" at any one moment is roughtly 8 seconds' worth... well within the ZMODEM protocol's ZRPOS timeout limit. If you're downloading over a noisy line, try sz -b -w 1024 foo.bin or even sz -b -w 512 foo.bin These commands will deliver 128- or 256-byte packets. Shorter packets are less likely to be corrupted by line noise, and may actually deliver better throughput. > Zterm > also seems to crash my MacIIcx on a far more regular basis than > any other program (except Boomerang). On the subject of ZTerm reliability... I haven't had any real problem with crashes with it on my Mac II, and it seems to work well now that my machine has been transmogrified into a IIfx. I did increase ZTerm's default memory allocation quite a bit, and take care to flush the scrollback buffer periodically. I _have_ found that ZTerm's ability to resume an interrupted ZMODEM download isn't 100% reliable... I've had a few files rendered unusable when I depended on this feature. I now prefer to slag down and completely retransmit any interrupted file... it's safer. I haven't had any notable problems with Boomerang (the release version). It's known to be incompatible with some programs, and one can add these to its exception list so it doesn't raise its head when those programs are in control.
vd09+@andrew.cmu.edu (Vincent M. Del Vecchio) (10/16/90)
On 15-Oct-90 in Re: Zterm woes user Dave Platt@coherent.com writes: >I _have_ found that ZTerm's ability to resume an interrupted ZMODEM >download isn't 100% reliable... I've had a few files rendered unusable >when I depended on this feature. I now prefer to slag down and >completely retransmit any interrupted file... it's safer. I think the problem is in it's handling of MacBinary files... at least, that's where I've had problems. Anyone else have similar experiences? +-------------------------------------------------------------------+ | Vincent Del Vecchio \ #include <stddisclaimer.h> | | Box 4834 \ #include <stdquote.h> | | 5125 Margaret Morrison St.\ BITNET: vd09+%andrew@cmuccvma.bitnet | | Pittsburgh, PA 15213 \ UUCP: harvard!andrew.cmu.edu!vd09 | | (412) 268-4441 \ Internet: vd09+@andrew.cmu.edu | +-------------------------------------------------------------------+
dm@everexn.com (Dan McMullen) (10/18/90)
in terms of reliability, one item to check is the window height in lines. if
this is less than 24, then one of the vt-100 terminal commands will crash
zterm. i'm not sure which one, but it has something to do with scrolling
the screen contents down? i get it when using the vi editor and openning a
new line. took me quite a while to figure that this was related to screen
size.
on an unrelated note, do others experience the annoying problem where the
modify time on files downloaded from zterm is set to some random value, often
later than the current time? sure makes makes a hassle.
--
dan mcmullen, everex systems, inc., sebastopol, ca. (707) 823-0733
dm@everexn.com ...!{well!fico2,pacbell!mslbrb}!everexn!dm