[159] in linux-net channel archive
Re: PPP and VJ compression problem
daemon@ATHENA.MIT.EDU (Bob Doolittle - Sun Parallel Open )
Tue Mar 28 19:11:59 1995
Date: Tue, 28 Mar 1995 14:04:20 -0500
From: rad@via.East.Sun.COM ( Bob Doolittle - Sun Parallel Open Systems)
To: scldad@sdc.com.au
Cc: linux-ppp@vger.rutgers.edu, linux-net@vger.rutgers.edu
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.
