papa@pollux.usc.edu (Marco Papa) (03/07/90)
In article <1990Mar7.000117.6984@ncsuvx.ncsu.edu> ml@ecerl3.UUCP () writes: >A semi-related question about throughput: > >The modem does all sorts of data compression techniques to get its speed. >Protocols like Zmodem also do compression. No. ZMODEM doesn't do any compression whatsoever. >Will the compression done by Zmodem (or "compress" or "arc" or "squeeze"...) >likely *decrease* the transmission rate when using data compression modes >(MNP or PEP) on the modem? (since applying a compression technique to data >which is already well compressed often yields *worse* results). If you "pre-compress" the program (whith compress, zoo, arc, squeeze) before sending the file, you WILL LIKELY *decrease* the transmission rate IF you've set up your modem to do compression itself. So best performance with modems that support compression can be achieved either by: a) transfer the original file "uncompressed", with your modem(s) compression turned ON. b) compress the file at the origination site and turn OFF your modem(s) compression. Most modem manuals will suggest you to do a). -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
bdb@becker.UUCP (Bruce Becker) (03/09/90)
In article <23299@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: |[...] |If you "pre-compress" the program (whith compress, zoo, arc, squeeze) before |sending the file, you WILL LIKELY *decrease* the transmission rate IF you've |set up your modem to do compression itself. So best performance with modems |that support compression can be achieved either by: | |a) transfer the original file "uncompressed", with your modem(s) compression | turned ON. | |b) compress the file at the origination site and turn OFF your modem(s) | compression. | |Most modem manuals will suggest you to do a). It seems that b). is the most advantageous however. Ususally the bottleneck is the time it takes to transfer data thru the serial port. for a). twice the amount of data (on average) goes through the port than for b). It usually takes a similar amount of time for the modem to compress as it does the host, so often there's no advantage to modem-based compression. Cheers, -- (__) Bruce Becker Toronto, Ontario w \@@/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `/v/-e UUCP: ...!uunet!mnetor!becker!bdb _/ \_ "They never tell you shit like this in high school!" - J. R. Dobbs
jross@pilot.njin.net (Jeff Ross) (03/10/90)
In article <5659@becker.UUCP>, bdb@becker.UUCP (Bruce Becker) writes: > In article <23299@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: > |[...] > |If you "pre-compress" the program (whith compress, zoo, arc, squeeze) before > |sending the file, you WILL LIKELY *decrease* the transmission rate IF you've > |set up your modem to do compression itself. So best performance with modems > |that support compression can be achieved either by: I have the microcom 2400c which is MNP lvl 5 I don't see anywhere in the manual where it says to turn off the modem compression if I am sending a compressed file. > | > |a) transfer the original file "uncompressed", with your modem(s) compression > | turned ON. on a standard text file (uncompressed) I can get about 460 cps throughput. > | > |b) compress the file at the origination site and turn OFF your modem(s) > | compression. > | > |Most modem manuals will suggest you to do a). > I find that by compressing the file first then sending the file across I can get a thoughput of about 280-300 cps depending upon the compression scheme used. > It seems that b). is the most advantageous > however. > > Ususally the bottleneck is the time it takes > to transfer data thru the serial port. > for a). twice the amount of data (on average) > goes through the port than for b). It > usually takes a similar amount of time for > the modem to compress as it does the host, > so often there's no advantage to modem-based > compression. > > Cheers, > -- > (__) Bruce Becker Toronto, Ontario > w \@@/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu > `/v/-e UUCP: ...!uunet!mnetor!becker!bdb > _/ \_ "They never tell you shit like this in high school!" - J. R. Dobbs a final nicety I have is that I only talk to the modem at 9600 bps, the modem and the computer nogotiate with each other via cts/rts to avoid overflowing the buffer. one other thing, transfers are error free due to the fact that compression modems are also error correcting modems. one of the big disadvantages is that while in the eror checking mode it is to your gread disadvantage to use an error checking protocol such as xmodem or ymodem because the modem does this itself with the remote. by what I can figure, the modems negotiate a packet size of on of the four sizes depending upon retry rates (64, 128, 192, 256 bytes) when a packet is recieved the remote sends its own acknoledgement, either send again or its ok. the problem comes is when the packet does not fill up, there is a time out where if no other data is to be sent, the modem just dumps its buffer. this is why using an error checking protocol is wasing time on the modems. either I will use ymodem-g or zmodem depending upon what the remote has available. Jeff -- Just plain and simple.... arpa: jross@pilot.njin.net uucp: uunet!tronsbox!wisdom!jeff