Thread (9 messages) 9 messages, 6 authors, 1999-09-28

Re: Inbound TCP Circuits over PPP Stall; MTUs and Kppp

From: Michel Lanners <hidden>
Date: 1999-09-27 19:57:52

Hi all,

On  27 Sep, this message from Randall R Schulz echoed through cyberspace:
At Paul M.'s suggestion, I tried using the "novj" option (only) in my 
~/.ppprc file. I made several tests against a few files on a couple 
of different servers.

The good news (at least as far as it offers a work-around): It does 
appear that disabling Van Jacobsen compression alleviates the symptom.
Aha...
However, I did also discover that even with VJ compression left 
enabled, not all remote hosts experience this problem.
[snip]
On the other hand, transferring files from "ftp.xemacs.org" (a.k.a. 
"gwyn.tux.org") is virtually impossible while VJ compression is 
enabled but works just fine with VJ disabled. In this case, my guess 
is that this host *does* run Linux.

It does also appear to be data related (not surprising if it's a 
problem with the implementation of the compression algorithm, whether 
in LinuxPPC 2.2.6 or whatever's running on ftp.xemacs.org). In 
particular this file: 
<ftp://ftp.xemacs.org/pub/xemacs/docs/letter/internals-letter.pdf.gz> 
will stall the TCP circuit after just a few K have been transferred. 
I repeated this twice and (like every file I tried) and it does 
transfer fine with VJ off.
OK, I saw similar things as well. I had more trouble with the
ftp.linuxppc.org server at that time (running some 2.1.x kernel), than
with my provider's HP server...
So, it may be the case that the LinuxPPC code in my kernel is OK (as 
evidenced by the fact that connecting to ftp.cris.com works OK) but 
that the implementation on ftp.xemacs.org is not correct or fully 
compliant with the VJ specification. It's also possible that my 
kernel's VJ code has a bug that is somehow tolerated by 
ftp.cris.com's VJ code.
EEeeeepppp.... wrong conclusion here ;-). VJ compression is only active
on your PPP link, not end-to-end. So the remote server knows nothing of
the VJ copmpression your machine negotiates with the access server at
your provider.

Which brings us to another variable in the connection chain: the access
server at your provider. In my case, it was a Cisco 2509 with
USRobotics modems. You might want to check with your provider, just in
case... If it really is a VJ problem, then the provider's box could
have an influence, too.
One last question: Can I turn VJ compression on and off while a PPP 
link is active, or must I choose before connecting?
I don't think Linux's PPP can renegotiate link parameters. In any case,
the remote end must then be prepared to renegotiate as well...

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help