Bug 8008 - Connection slows down to a crawl... then stalls
Connection slows down to a crawl... then stalls
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: ppp (Show other bugs)
6.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-12-27 10:16 EST by Tim Teller
Modified: 2008-05-01 11:37 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-12-13 20:58:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tim Teller 1999-12-27 10:16:42 EST
Similar to Bug 7180 (Worldnet slow).  I get connected just fine, and the
speeds are right.  I launch Netscape, and browse.  Then the performance
starts degrading... 100 Bytes/Sec ...  8 Bytes/Sec ... Stalled.

I opened up a Xterm and did a ifconfig and noticed that I have a high
number of errors, actually the same number for frames as errors on the Rx
side.

Any Ideas?

Tim Teller
Comment 1 noah 2000-02-05 15:55:59 EST
I am having similar problems.  It occurs not only in Netscape, but in lynx, ftp,
and telnet as well.  It seems to be more common when a large burst of data comes
in, ie. a long web page.  Like this bug report, I am also seeing a large number
of frame errors in ifconfig.  I installed the ppp and initscripts upgrades from
the errata page but this didn't help.  Nothing strange in /var/log/messages, but
I do notice that software compression is enabled:

Feb  5 15:21:53 localhost kernel: PPP BSD Compression module registered
Feb  5 15:21:53 localhost kernel: PPP Deflate Compression module registered
Comment 2 noah 2000-02-07 01:35:59 EST
For what it's worth, I figured out how to turn off the software compression, but
it didn't fix my problem.
Comment 3 butler 2000-02-08 07:52:59 EST
I am also having the same problem. Have tried upgrading ppp and turning off
compression. By turning off compression the connect stays up slightly longer I
believe. No problem with the hardware as it works fine under windows. I have
also found that I can restart the transfer and that it will work fine for a
while again than stall.


I was wondering whether it could be a bug on the ppp server end in MS NT
implimentation of PPP protocol.
Comment 4 noah 2000-02-08 21:01:59 EST
My ISP is running SunOS 5.5.1, so it can't just be an NT problem.  My modem
and ISP work fine under Win95 also.  I'm using an external modem, so I tried
switching COM ports, but got the same symptoms on both (ttyS0 and ttyS1).
Comment 5 butler 2000-02-09 06:00:59 EST
My connection seems much better by turning off vj header compression in pppd by
adding the option novj. Not sure why this should be the case ? Unless the
sending in is compressing the header incorrectly. I suspect that windows PPP
does not use any software compression of any type, that is why it works........

Harry
Comment 6 noah 2000-02-09 20:04:59 EST
Yes, that seems to be working!  The novj option seems to have fixed it.  I've
been going to sites that usually make it stall, and no freeze ups yet. I'm still
seeing frame errors in ifconfig, but I don't know if that is worth worrying
about.  Thanks for your help!
Comment 7 Nalin Dahyabhai 2000-02-29 11:35:59 EST
This is odd.  Could I ask which ISPs you are all using?
Comment 8 Tim Teller 2000-02-29 13:05:59 EST
I dial into Rocky Mountain Internet, v.90 pool.

I also dial into an Cisco AS/5200 that I administrate.  The modems are v.90
Mincom modems.  I can probably provide you a lot of debugging info.  If you
want.   -Tim Teller
Comment 9 noah 2000-02-29 23:00:59 EST
I'm using FYI Networks(fyi.net), a small Pittsburgh ISP.  Like I said they are
running SunOS 5.5.1.  Since I added the novj to my PPP options I haven't had any
more problems.
Comment 10 Joseph Smith 2000-07-23 01:26:03 EDT
I am using two ISP's and get the same behavior on both.  First the connection
starts off fine, but soon it starts to slow down and stall. One of the ISP seems
to take longer to slowdown and stall, after using novj. Although it still always
stalls after a few web page downloads. Restarting the connection results in
stalling immediately, unless I restart computer.  Also starting one connection
running it untill it stalls and then starting the other connection causes the
second to immediately start to stall. I am using a ELSA MicroLink 56K external
modem, which is a ISDN device?
Comment 11 Bradd W. Szonye 2000-08-07 15:34:04 EDT
I have a similar problem; the overall connection is fine, but individual TCP
transfers (like FTPing large files or downloading a large POP3 mailbox) stall
after a few dozen kilobytes. I'm using a 56K modem with Concentric.net as ISP.
Nothing yet has helped; I have tried -vj, asyncmap 0, mru 552, and a variety of
other recommended solutions. Through this, I have discovered what appears to be
a bug in the (kernel portion) ppp.c driver: if you attempt to set the MRU less
than the default of 1500, it sets it to the default. I believe what's intended
is that it fixes it up if you set it less than the *minimum*, which is 128. I am
working on rebuilding the kernel with this driver fix to see whether it helps my
problem.
Comment 12 Bradd W. Szonye 2000-08-07 15:41:45 EDT
Oh, to reproduce the bug I found, enable 'mru 552' and 'kdebug 7' in pppd, then
examine the log output in /var/log/messages. Despite requesting mru 552, it will
report 'ppp_ioctl: set mru to 5dc' (0x5dc = 1500).

I can't tell for certain, but I suspect that 1500 is too large a packet size for
my dialup connection. It probably results in worse throughput for other users as
well, although not necessarily as dramatic as a total freeze. MRU 552 is much
more appropriate for a fast modem.
Comment 13 Bradd W. Szonye 2000-08-07 17:18:32 EDT
On further looking, it's possible that the MRU thing is not a bug... at this
point I'm not sure. It may be that the ppp driver doesn't care if the MRU is
less than its default. Still, it seems suspicious to me, so it may be worth
checking out.
Comment 14 Bradd W. Szonye 2000-08-07 20:53:05 EDT
Okay, I managed to fix my own problems, for now at least. Turning off VJ header
compression in ppp is one way. (This didn't work for me before; I was using the
"-vj" syntax suggested in the pppd options file, which didn't work, but "novj"
seems to do it.)

The root cause is (as I understand it) an incompatibility with TCP timestamps
(from RFC 1323) and VJ header compression (from RFC 1144). Basically, you have a
choice: disable VJ or disable timestamps. You can do the former with pppd
options; to turn off TCP timestamps instead, use sysctl to deselect the kernel's
runtime tcp_timestamps option. I don't know whether you also need to turn off
tcp_window_scaling or tcp_sack (two more RFC 1323 options) as well. You may want
to try both approaches (novj and no tcp_timestamps) to see which one gives you
better throughput.

My connection is currently running much better. This may explain why.
Comment 15 Alan Cox 2002-12-13 20:58:04 EST
There were bugs in several vendors handling of vj+timestamp combos, and some
obscure Linux cases too. All seem to have been fixed over time.

If not re-open

Note You need to log in before you can comment on or make changes to this bug.