Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!motcid!koch From: koch@motcid.UUCP (Clifton Koch) Newsgroups: comp.dcom.modems Subject: Re: How to increase throughput on 9600 bps modem? Message-ID: <5818@navy22.UUCP> Date: 14 Dec 90 17:21:05 GMT References: <17@ghost.UUCP> Organization: Motorola Inc., Cellular Infrastructure Div., Arlington Heights, IL Lines: 67 From article <17@ghost.UUCP>, by kianusch@ghost.UUCP (Kianusch Sayah-Karadji): ->> ->>Most binary files transfer from my Mac IIcx through the 9600 V.32 ->>modem to the remote site (Telebit T2500) at about 300 bps -> 600 bps. ->>Text files (like Macintosh HQX files) transfer at around 900 bps. ->>ZMODEM claims that 900 bps is 98 percent effeciency. Ok... let's ->>assume ZMODEM is telling the truth when it says that 1000 bps is the ->>best I can expect. Why is it that binary files are doing the snail's ->>pace of 300? ->> ->>There's more to it than that actually. Very often the performance ->>gets as low as 60 bps! This is apparently because the transmissions ->>are very "bursty" in character. There will be a sudden burst of ->>characters to the remote modem and then a LONG 5 second delay of dead ->>air and then a little more traffice and then another LONG delay of say ->>10 seconds and so on ad nauseum. Is this because ZMODEM is getting ->>NAK packets of some kind back and retransmitting? Why the LONG ->>delays? ->> ->>Here's another fun bit of info. Transfers from the remote machine TO ->>my Mac are FAST! Always. Binary and ascii data crank at 98 percent ->>effeciency all the time. Now why in the world would reception be ->>faster than transmission? -> -> ... if you modems have compression mode don't use Zmodem -> (use Y/X modem instead) ... if you do want to use Zmodem ... turn modem -> compression of and use only local error correction... same thing with -> compressed files, (zoo, compress, zip, ...) dont use Zmodem or Modem -> compression at all. -> -> The reason is that each of those try compress the data... -> -> worst scenario... transfering a compressed file, with -> zmodem using an compression modem protocoll... -> -> zmodem try's to compress ... but actually makes the file bigger ... -> now the modem get's a big-compressed file, which the modem in turn -> tries to compress ... and makes it even more bigger ... and everything -> slowes down... -> -> happend to me a few days ago... trying to tranfer a compressed (700k) file... -> using telebit PEP / COMPRESSION ... it took me 30min for the first 300k ... -> I aborted the transfer ... started all over again using PEP only -> (no compression) ... and the transfer was compleated in 12 minutes... -> -> Text files are not compressed... so either Zmodem, or Modem-compression will -> do a better job... Zmodem does not compress the data. I use Zmodem almost exclusively and get about a 1650 CPS transfer with a USR HST and compression turned off on binary files. Zmodem is a streaming protocol and there should be no return data unless and error is detected in the recieve data or end of file is reached. I found that if I turn modem compression on during a binary transfer, the data rate drops ~30%. It takes me about 10 minutes to transfer a megabyte with Zmodem. It sounds more like there is some sort of handshaking/protocol problem. Most versions of Zmodem will revert to X or Y modem if the Zmodem handshaking fails, so there will be ACK/NACK handshaking going on. I would make a guess that data size/parity/stop bits/something along these lines are messed up. The transfer gets set up OK, but then gets hung up later because the ACK/NACK messages are not being recognized properly. The looong delay is from the protocol timing out on the receipt of a message. -- ----------------------------------------------------------------------------- .. [uunet | mcdchg | gatech]!motcid!koch