Xref: utzoo comp.dcom.modems:8918 comp.unix.questions:29706 comp.unix.admin:1378 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!uwm.edu!linac!midway!mimsy!nocusuhs!nmrdc1!minixug!root From: root@minixug.mugnet.org (MINIXUG-ONLINE System Manager) Newsgroups: comp.dcom.modems,comp.unix.questions,comp.unix.admin Subject: Re: DSZ ZMODEM problem Message-ID: <910322399@minixug.mugnet.org> Date: 22 Mar 91 21:32:58 GMT References: <1991Mar18.151002.1423@crom2.uucp> Organization: MINIX User Group Holland (NLMUG) - MUGNET - Lines: 44 jim@crom2.uucp (James P. H. Fuller) wrote: > > I'd like to hear about this also. I have Forsberg's rz and sz compiled > for ISC Unix rel.2.2 (SysVr3.2) and whenever people call from DOS machines > and try to download stuff using dsz they get lots of timeouts and error re- > covery and a very low transfer rate. My modem is a T2500 with the registers > optimized (as best I can) for unix/uucp. Also my rz/sz is fairly old, since > it's what came as a freebie on the disk Omen Tech sent me when I registered > dsz-for-DOS a couple of years ago. Would a newer rz/sz help, or is it my > modem settings or something else? My serial card has only a 16450 UART, but > all the errors happen even at 2400bps, so it doesn't seem that the lack of > a buffer is the problem. Ahh. I run a number of UNIX and MINIX (yes!) machines over here (work and home), and I also observed funny behaviour with rz/sz ... I use Telebit Trailblazer modems here, and I noticed that when _downloading_ from the UNIX systems (Interactive IX/386, BTW), all went well: just a continuous byte stream coming in. However, when _uploading_ a file from any MINIX system, I found that Zmodem was waiting for ACKs every 1024 bytes. When using 19200bps-or- above links, this means a drop in performance of about 50% :-( I then installed the 3.06 version of rz/sz (I was using something like 1.18), but that didn't do any good. Then I noticed a little remark in the sources about non-blocking I/O on UNIX-ish systems... It turned out, that when I recompiled the programs with my version of non-blocking I/O (I implemented the TIOCICNT call in MINIX's ioctl(2)), all went perfect.... So: when rz/sz is _slow_, you may want to recompile with non-blocking I/O enabled. when rz/sz is _bad_, you may suffer from a bad handshake with the modem(s). Many UNIX systems do not properly handshake with the modem(s) (with RTS/CTS and/or XON/XOFF), which, with high-speed modems, or modems with an interspeeder, causes data loss... Hope this helps, Fred van Kempen