Return to BSD News archive
Newsgroups: comp.os.386bsd.questions Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!pipex!uunet!magnesium.club.cc.cmu.edu!honeydew.srv.cs.cmu.edu!crabapple.srv.cs.cmu.edu!jch From: jch@CS.CMU.EDU (Jonathan Hardwick) Subject: Re: ed0: device timeout, freebsd cslip In-Reply-To: pitts@bigbang.astro.indiana.edu's message of Mon, 4 Oct 1993 14:39:58 GMT Message-ID: <CEEIAC.LoA.1@cs.cmu.edu> Originator: jch@GS69.SP.CS.CMU.EDU Sender: news@cs.cmu.edu (Usenet News System) Nntp-Posting-Host: gs69.sp.cs.cmu.edu Reply-To: jch@cs.cmu.edu (Jonathan Hardwick) Organization: School of Computer Science, Carnegie Mellon University References: <1993Oct3.020559.16808@zen.void.oz.au> <CECt8C.29o@Colorado.EDU> <JKH.93Oct4083135@whisker.lotus.ie> <CEDnEn.D9r@usenet.ucs.indiana.edu> Date: Tue, 5 Oct 1993 01:46:57 GMT Lines: 41 pitts@bigbang.astro.indiana.edu (Jim Pitts) writes: > The compression features of 14.4K modems can actually HURT your transfer > rate on gzipped files that are ALREADY compressed. Remember that your > modem has to spend time compressing files before it sends them (that > is how it gets to the speeds it does at some level). If there is > little redundancy in the data you are transmitting, this can slow you > down a good bit. I would suggest if you want to compare to other peoples > numbers you provide the transfer rates for: > > 1. gzip'ped files (packed binaries). > 2. ASCII text files. > 3. Executable binaries (non packed binaries). > > Do this for files above 500K in size to get good statistics. Finally, after > you do this with ftp, do the same tests with zmodem. You should get > 1.4K/s for binaries, 1.2K/s for packed binaries, and almost 2K/s for ASCII > files. I don't agree with all of this. Using MNP5 compression on precompressed data will almost certainly hurt you. However, the more modern v.42bis compression (which every new 14.4k modem I've seen supports) can tell when compression isn't helping and "gets out of the way". It'll add maybe 50ms latency for a poor implementation, less on a good modem. Using just v.42 error-correction will boost your throughput by slightly under 20% -- it strips off the stop and start bits, thereby sending 8 bits as 8 bits, rather than 10 bits, so you get 14400/8 = 1.8k rather than 14.4/10 = 1.44k (actually slightly less than 1.8k because of the protocol overhead). Again, compared to a raw v.32bis connection it'll add latency, but less than that of error-correction + compression. Anyway, using CSLIP and a 552-byte MTU over a v.42bis connection, I get 1.7kbytes/s for anything gzip'd, and up to 3kbytes/s for ASCII files. I've also verified that just using v.42 limits everything to 1.7kbytes/s. This is with a Sun3/50, so don't ask me how I did it in 386bsd (:->), but the modem and the CSLIP protocol are just the same... comp.dcom.modems is a good place to talk about the details of v.42bis and what it can and can't give you. Jonathan H