*BSD News Article 21881


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