Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 12 Jan 1996 11:20:30 -0500 (EST)
From:      "Michael C. Newell" <mnewell@lupine.nsi.nasa.gov>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        nate@sri.MT.net, hackers@FreeBSD.ORG
Subject:   Re: pppd vs ijppp
Message-ID:  <Pine.SUN.3.91.960112110535.14135G-100000@lupine.nsi.nasa.gov>
In-Reply-To: <199601120722.SAA25365@godzilla.zeta.org.au>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 12 Jan 1996, Bruce Evans wrote:

> >Is the module in ijppp also encumbered?
> 
> Probably.
> 
> The standard BSD-compress in the current kernel ppp (and in /usr/bin)
> is also apparently encumbered.  See /usr/src/usr.sbin/pppd/RELNOTES.

Is compression already in the kernel ppp?  I've not looked (yet - that's 
my project for today.  Being snowed in has it's advantages! :-)  I know 
the 'compress(1)' mechanism (LZW) is patented, but I thought there was 
some debate about wether or not a patent claim can be enforced after 
laying dormant for so many years?  Fortunately I'm not a lawyer... :-)

Still, I don't believe *ALL* forms of compression are patented!! :-)!!

> Doesn't your modem do compression?  I don't see how compression can
> help if it does.  BSD-compress (15 bits) only achieves 33% compression
> on /kernel (a average (?) non-text non-compressed file) at a cost of
> approximately doubling the total transmission overhead on a 486DX2/66.
> For compressing /kernel.gz, /usr/bin/compress _expands_ the file by 40%.

Yes, supposedly they do.  But the throughput I get is only on the order of
2KB/s on precompressed binary files, 2.7KB/s on plain text (uncompressed)
binary files.  The modem reports that it has negotiated a compressed
connection usually at 26.4Kb/s (I've not see lower), and I'm running the
DTEs at 115.2Kbs, so I'm not sure what's going on.  I'm seeing this with
both the Hayes Accura 2.88 V.FC+FAX and the Zoom 28.8 (also V.FC) modems. 
I use pairs of modems (i.e. the Hayes modem talks to another Hayes of the
same type; as do the Zooms) so it's not cross-vendor incompatabilities. 

I'm using RTS/CTS flow control.  The PPP server is a 486SX-33 with 4 16550
ports (only 2 in use) used ONLY as a PPP server for 2 lines (see
"http://lupine.nsi.nasa.gov/~mnewell/mcnet.html" for details; the second
ethernet shown in the diagram is not currently in use).  The clients are
486DX-2 66 and 100 boxes.  There doesn't appear to be a problem with
errors; errors are about 5 in 40,000 packets. 

Very disappointing results.  Any ideas along that route would be
appreciated... :-) With ijppp + predictor-1 I was getting 3.3KB/s on
compressed binary files, and 3.7KB/s on plain ASCII text files (but the
only way to stay up long enough to acquire large enough files for
meaningful statistics was to lower the speed of the serial ports to
38.4Kb/s). 

Thanks,

Mike

+--------------------------------------+------------------------------------+
|Mike Newell                           | The opinions expressed herein are  |
|NASA Science Internet Network Systems | my own, and do not necessarily     |
|Sterling Software, Inc.               | reflect those of the NSI program,  |
|MNewell@nsipo.nasa.gov                | Sterling Software, NASA, or anyone |
|+1-202-434-8954                       | else.                              |
+--------------------------------------+------------------------------------+
|                  work: http://www.eco.nsi.nasa.gov/~mnewell               |
|                    home: http://www.newell.arlington.va.us                |
+---------------------------------------------------------------------------+




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.960112110535.14135G-100000>