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
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
For what it's worth, I figured out how to turn off the software compression, but it didn't fix my problem.
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.
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).
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
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!
This is odd. Could I ask which ISPs you are all using?
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
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.
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?
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.
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.
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.
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.
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