From owner-freebsd-hackers Fri Jan 12 08:23:50 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA19264 for hackers-outgoing; Fri, 12 Jan 1996 08:23:50 -0800 (PST) Received: from lupine.nsi.nasa.gov (lupine.nsi.nasa.gov [198.116.2.100]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA19256 for ; Fri, 12 Jan 1996 08:23:44 -0800 (PST) Received: (from mnewell@localhost) by lupine.nsi.nasa.gov (8.6.12/8.6.12) id LAA15105; Fri, 12 Jan 1996 11:20:31 -0500 Date: Fri, 12 Jan 1996 11:20:30 -0500 (EST) From: "Michael C. Newell" To: Bruce Evans cc: nate@sri.MT.net, hackers@FreeBSD.ORG Subject: Re: pppd vs ijppp In-Reply-To: <199601120722.SAA25365@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk 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 | +---------------------------------------------------------------------------+