jtn@ADS.COM (John T. Nelson) (12/13/90)
Thanks to all who responded to my query about the Racal Vadic 9632 VP modem. I've got ZMODEM running now (without hardware handshake!) but looking at the throughput I have even MORE questions! 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? At least it works. I disable ALL flow control and use the latest copy of "rz" from mpace.cs.purude.edu (I think that's the place) and use the full 8 bit data path. Enjoy. -- ORGANIZATION: Advanced Decision Systems GEOGRAPHIC: Arlington, VA UUCP: kzin!speaker@mimsy.umd.edu INTERNET: jtn@potomac.ads.com SPOKEN: John T. Nelson PHONE: (703) 243-1611 PROJECT: Macintosh hacking -- "Love the Machine... Hate the Company"
lriggins@blackbird.afit.af.mil (L. Maurice Riggins) (12/13/90)
In article <9PF^W}#@ads.com> jtn@ADS.COM (John T. Nelson) writes: >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? >At least it works. I disable ALL flow control and use the latest copy >of "rz" from mpace.cs.purude.edu (I think that's the place) and use >the full 8 bit data path. I experience the same thing here. But with the bsd system, I have to call sz with -w 8194 and ZNULLS set to 124 (for my SE) to get sz to work. Not may retransmissions (if any) on upload or download. Do have stty -tandem set also. I'm using White Knight with a Practical Peripherals PM9600SA going into a UDS 9600 (MNP only) which feeds a TRW ACU (with hardware handshake) going through Ethernet to the Vax. Any clues (other than the Vax buffers can't handle it)? Thanks, -- Maurice INTERNET: lriggins@blackbird.afit.af.mil (129.92.1.2) Opinions expressed here do not reflect those of my employer nor constitute an official position of any U.S.Government agency.
kianusch@ghost.UUCP (Kianusch Sayah-Karadji) (12/14/90)
> >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... Hope This helps Kianusch -- Kianusch Sayah-Karadji srhqla!unigold!ghost!kianusch kianusch@ghost.UUCP pacbell!unicom!ghost!kianusch
koch@motcid.UUCP (Clifton Koch) (12/15/90)
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
leonardr@svc.portal.com (Leonard Rosenthol) (12/15/90)
In article <17@ghost.UUCP>, kianusch@ghost.UUCP (Kianusch Sayah-Karadji) writes: > ... 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... > THIS INFORMATION IS INCORRECT!! It is true that you do not want to send compressed files across a modem on which compression is enabled - but the protocol doesn't make a difference, especially ZMODEM. All of the current Macintosh ZMODEM implementations, and most of the PC/UNIX, etc. DO NOT support compression! The ZMODEM spec does provide hooks for RLE compression, but Forsberg never recommended implementation due to lack of standardization. His new ZMODEM-90 (Moby-Turbo) provides for a standard RLE compression across ZMODEM implemenation, so some newer products may offer it as an option, but you will not yet find one on the Mac or UNIX (rzsz). And to my knowledge, only dsz on the PC has the ZMODEM-90 extentions. -- ---------------------------------------------------------------------- + Leonard Rosenthol | Internet: leonardr@sv.portal.com + + Software Ventures | GEnie: MACgician + + MicroPhone II Development Team | AOL: MACgician1 + ----------------------------------------------------------------------
daven@svc.portal.com (12/15/90)
In article <17@ghost.UUCP> kianusch@ghost.UUCP (Kianusch Sayah-Karadji) writes: > > 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... > Say, enlighten me. What ZMODEM are you using that has compression built into ZMODEM? I've yet to see one that does this. Though Forsberg describes the potential for comperssion in ZMODEM, he nor anyone else has yet to implement it to the best of my knowledge. -- ------------------------------------------------------------------------------- Dave Newman | daven@svc.portal.com | AppleLink: D0025 Sofware Ventures Corp. | AOL: MicroPhone | CIS: 76004,2161 Berkeley, CA 94705 | WELL: tinman@well.sf.ca.us | (415) 644-3232
ron@woan (Ronald S. Woan) (12/16/90)
In article <1990Dec14.174237.1708@svc.portal.com>, leonardr@svc.portal.com (Leonard Rosenthol) writes: Lenny> THIS INFORMATION IS INCORRECT!! It is true that you do not Lenny> want to send compressed files across a modem on which Lenny> compression is enabled - but the protocol doesn't make a Lenny> difference, especially ZMODEM. All of the current Macintosh Lenny> ZMODEM implementations, and most of the PC/UNIX, etc. DO NOT Lenny> support compression! The ZMODEM spec does provide hooks for Lenny> RLE compression, but Forsberg never recommended implementation Lenny> due to lack of standardization. His new ZMODEM-90 (Moby-Turbo) Lenny> provides for a standard RLE compression across ZMODEM Lenny> implemenation, so some newer products may offer it as an Lenny> option, but you will not yet find one on the Mac or UNIX Lenny> (rzsz). And to my knowledge, only dsz on the PC has the Lenny> ZMODEM-90 extentions. This is strange indeed... The rzsz from Omen that I used a few years ago at college had a compression option as did dsz from Omen... Moby-Turbo is not compression, just a way of sending with less overhead... Read the doc.s that come with dsz for details... +-----All Views Expressed Are My Own And Are Not Necessarily Shared By------+ +------------------------------My Employer----------------------------------+ + Ronald S. Woan woan@peyote.cactus.org or woan%austin@iinus1.ibm.com + + other email addresses Prodigy: XTCR74A Compuserve: 73530,2537 +
kianusch@ghost.UUCP (Kianusch Sayah-Karadji) (12/17/90)
... I write ... }> ... 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. } THIS INFORMATION IS INCORRECT!! It is true that you do not want } to send compressed files across a modem on which compression is enabled - } but the protocol doesn't make a difference, especially ZMODEM. All of the } current Macintosh ZMODEM implementations, and most of the PC/UNIX, etc. DO } NOT support compression! The ZMODEM spec does provide hooks for RLE } compression, but Forsberg never recommended implementation due to lack of } standardization. His new ZMODEM-90 (Moby-Turbo) provides for a standard } RLE compression across ZMODEM implemenation, so some newer products may offer } it as an option, but you will not yet find one on the Mac or UNIX (rzsz). } And to my knowledge, only dsz on the PC has the ZMODEM-90 extentions. } } + Leonard Rosenthol | Internet: leonardr@sv.portal.com + >Say, enlighten me. What ZMODEM are you using that has compression built into >ZMODEM? I've yet to see one that does this. Though Forsberg describes the >potential for comperssion in ZMODEM, he nor anyone else has yet to implement >it to the best of my knowledge. > > Dave Newman | daven@svc.portal.com | AppleLink: D0025 ... OKAY ... I change my words ... U can use the Zmodem protocoll, but don't turn it's compression on! About the INCORRECT INFORMATION, and the enlightment... Maybe all you guy's should bring your Zmodem programs up to date. :-) You are ten month behind! It's available at SIMTEL. (sz 3.07 2-02-90) ^^^^^^^ ... typing 'sz' with no arguments at my unix prompt gives me ... --- Send file(s) with ZMODEM/YMODEM/XMODEM Protocol (Y) = Option applies to YMODEM only (Z) = Option applies to ZMODEM only Usage: sz [-2+abdefkLlNnquvwYyZ] [-] file ... . . stuff deleted . Z Activate ZMODEM compression(Z) ^^^^^^ ^^^^^^^^^^^ sz 3.07 2-02-90 for SYS III/V by Chuck Forsberg, Omen Technology INC ^^^^^^^^ "The High Reliability Software" --- -- Kianusch Sayah-Karadji srhqla!unigold!ghost!kianusch kianusch@ghost.UUCP pacbell!unicom!ghost!kianusch
cummins@d.cs.okstate.edu (John Cummins) (12/17/90)
In article <5818@navy22.UUCP> koch@motcid.UUCP (Clifton Koch) writes: >From article <17@ghost.UUCP>, by kianusch@ghost.UUCP (Kianusch Sayah-Karadji): > >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 Thats exactly what I had until I matched my flow control on my computer to the flow control on the modem. Now I get about 1200 cps upload and 1650 cps download. Check it out. If you see the CTS light go out on your modem... (whan a BURST is in progress) and the TD light doesn't go out very quickly... then you have a hardware handshake from your modem that is being ignored by your PC... (I know it's a mac... but it's still a Personal Computer... no?) Could be a cable problem, or a software setup problem. (How about a response from a Mac user on cables and Flow control settings) cummins@d.cs.okstate.edu