[165] in linux-net channel archive

home help back first fref pref prev next nref lref last post

Re: PPP and VJ compression problem

daemon@ATHENA.MIT.EDU (Stephen Davies)
Wed Mar 29 10:15:21 1995

From: "Stephen Davies" <scldad@sdc.com.au>
To: Bob Doolittle - Sun Parallel Open Systems <rad@via.East.Sun.COM>
Cc: scldad@sdc.com.au, linux-ppp@vger.rutgers.edu, linux-net@vger.rutgers.edu
Date: Wed, 29 Mar 95 22:15:16 +0930
In-Reply-To: Your message of Tue, 28 Mar 1995 14:04:20 -0500.<9503281904.AA00499@via.East.Sun.COM>

G'day Bob.

Thank you for your feedback - particularly your views on asyncmap.

Are you sure you have this right? I thought it worked the other way around
and that an explicit map of all zeroes meant "do not escape anything" and
that no asyncmap arg at all meant "escape everything".

To get the verbose log, I add kdebug and debug options to my pppd call.
This causes pppd to log verbosely to syslog at debug level. I also
included /usr/spool/uucp/Log.

I spoke again yesterday to my ISP and they are not sure that it is not their
fault. They are having problems with their CISCO boxes and agree that the
problem "might" lie there. We will experiment some more over the next
few days.

Cheers,
Stephen.

>       I'm sorry I don't have any specific advice for your problem.
>I've had similar problems in the past that I currently suspect are
>related to a broken ppp on the remote end, which I can't do anything
>about, unfortunately.
>       I'd be interested in how you got this log.  In particular, how
>did you get pppd to generate such verbose output?  I don't see the
>debug switch on your command line.  Where is the log itself?
>       I would suspect that you probably lose more bandwidth by totally
>turning off the asyncmap than you lose by turning off the VJ protocol.
>Statistically speaking, completely turning off the asyncmap should eat
>13% of your bandwidth off the top (ctl chars = 25% of ASCII chars,
>escaping these halves your bandwidth).  Typically you really only need
>to escape about 4 characters, which would eat only 2% of your
>bandwidth.  Do you know the specifics of what VJ compression buys you?
>I know with no compression at all, a TCP/IP header is 40 bytes, but I
>don't know how small this gets after the other compressions (non-VJ)
>are performed, nor do I know how big a VJ header is.  Any data would be
>welcome.
>       Isn't there some way of determining automatically what maximal
>asyncmap can be used safely over your link?  Other similar serial-line
>protocols do this (e.g.  term).  In fact, you could probably use these
>tools to determine your best asyncmap for PPP (it might be a slight
>superset, but better than 00000000)!
>
>Good luck!
>
>-Bob
>
>P.S. Are dialing in to a different modem pool now that you are using
>28.8K?  If so, perhaps they use a different terminal server?  It is
>common for terminal servers to be confused by VJ protocol.

========================================================================
Stephen Davies Consulting                              scldad@sdc.com.au
Adelaide, South Australia.                           Voice: 61-8-2728863
Computing & Network solutions.                       Fax  : 61-8-2741015

home help back first fref pref prev next nref lref last post