Messages in this thread | | | Date | Sat, 27 Jul 1996 23:37:07 -0600 (MDT) | From | Rob Riggs <> | Subject | Sporadic slow PPP connections |
| |
Hi Alan, Linus...
I'm having a problem with network connections. I'm not sure when this started exactly, but I have been noticing sporadic slow PPP speed over the last month or so. I first thought that it was my ISP's problem, but I could not (at the time) duplicate the slowdown.
Over the last week or so I began to notice that the slowdowns occured while Netscape (3.0b4) was left up between bringing the PPP down and then back up again. I use kerneld to bring up my PPP connection and have pppd timeout after 10 minutes and bring down the connection. Right before the PPP connection is closed I will occasionally notice the following:
Proto Recv-Q Send-Q Local Address Foreign Address (State) User tcp 1 0 dialup166.tesser.:1437 netrover.com:www CLOSE_WAIT rob tcp 1 0 dialup166.tesser.:1436 netrover.com:www CLOSE_WAIT rob
This will stay in this state the entire time that the PPP connection is down. When I bring up the PPP connection later, the connections in CLOSE_WAIT will stay that way for quite some time. A while later it will switch to:
Proto Recv-Q Send-Q Local Address Foreign Address (State) User tcp 1 1 dialup166.tesser.:1437 netrover.com:www LAST_ACK root tcp 1 1 dialup166.tesser.:1436 netrover.com:www LAST_ACK root
Of course the "Foreign Address" is whatever I had Netscape connected to last. The connection is *very* slow. I get 1-2 second ping delays to the *terminal server* one hop away. Very bad indeed. The only way to fix this is to allow the CLOSE_WAIT and LAST_ACK to timeout, then bring down the PPP connection. Once re-established, the PPP connection performs as it should. This last bit about bringing the PPP connection down then up could be superstition on my part. I need to test this assumption some more.
This behaviour doesn't seem to occur with all web pages. When Netscape is pointed to www.yahoo.com, for instance, it goes through CLOSE_WAIT and LAST_ACK very quickly. I'd say within a few seconds of completing the page transfer. It seems that some others, however, seem to never close the connection properly until Netscape exits. If the PPP interface goes down, even for a short while, Netscape cannot close the connection properly.
I just noticed... the connect state will switch from CLOSE_WAIT to LAST_ACK after I close Netscape. I'm not 100% sure (i don't *think* it does) that this happens every time. Also... bringing the PPP connection down while in LAST_ACK seems to completely close the connection. (Not tested)
If I start and close Netscape during the same PPP session, the same connections that cause the problems close as they should. The fact the kerneld is starting the PPP connection has nothing to do with the problem, since it occurs if I manually start and shut down the PPP link. PPP is loaded as a module, but it doesn't matter if the module unloads or stays resident between the time PPP connection goes down and comes back up.
It's late and I'm tired. I may have mis-interpreted some of the interactions. I did not duplicate all of the minor details. But the PPP slowdown is very repeatable for me. Connect via PPP. Start Netscape. Point it to http://www.netrover.com/~eyevet/irc.html. Wait for the page to finish loading. Bring down the PPP connection. Check netstat - it should give connection in CLOSE_WAIT. Restart PPP. PPP is now *very* slow.
Now... I have a couple of questions: 1. Does this make any sense whatsoever? 2. Is there any way to manually close a connection? (the connection will stay in LAST_ACK until it times out after Netscape exits.) 3. Anyone else noticing this?
Rob (rriggs@tesser.com)
P.S. In case you need it:
Linux diamond 2.0.8 #1 Sat Jul 20 01:24:49 MDT 1996 i586
CONFIG_EXPERIMENTAL=y
CONFIG_MODULES=y CONFIG_KERNELD=y
CONFIG_NET=y CONFIG_PCI=y CONFIG_PCI_OPTIMIZE=y CONFIG_SYSVIPC=y CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_JAVA=m CONFIG_KERNEL_ELF=y CONFIG_M586=y CONFIG_M586_COPY=y
CONFIG_BLK_DEV_FD=y CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_CMD640=y CONFIG_BLK_DEV_TRITON=y CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_RAM=m
CONFIG_FIREWALL=y CONFIG_INET=y CONFIG_IP_FORWARD=y CONFIG_IP_FIREWALL=y CONFIG_IP_FIREWALL_VERBOSE=y CONFIG_IP_MASQUERADE=y
CONFIG_IP_TRANSPARENT_PROXY=y CONFIG_IP_ALWAYS_DEFRAG=y CONFIG_IP_ACCT=y CONFIG_NET_IPIP=m
CONFIG_INET_RARP=m CONFIG_IP_NOSR=y CONFIG_SKB_LARGE=y
CONFIG_IPX=m CONFIG_ATALK=m
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=m CONFIG_BLK_DEV_SR=m CONFIG_CHR_DEV_SG=m
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_NCR53C8XX=y CONFIG_SCSI_NCR53C8XX_TAGGED_QUEUE=y
CONFIG_NETDEVICES=y CONFIG_DUMMY=m CONFIG_PPP=m
CONFIG_SLIP=m CONFIG_SLIP_COMPRESSED=y CONFIG_NET_ETHERNET=y CONFIG_NET_ISA=y CONFIG_NE2000=m
CONFIG_CD_NO_IDESCSI=y CONFIG_SBPCD=m
CONFIG_MINIX_FS=y CONFIG_EXT2_FS=y CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=m CONFIG_PROC_FS=y CONFIG_NFS_FS=m CONFIG_SMB_FS=m CONFIG_NCP_FS=m CONFIG_ISO9660_FS=y
CONFIG_SERIAL=y CONFIG_PRINTER=m CONFIG_RTC=y
CONFIG_SOUND=y CONFIG_SB=y CONFIG_ADLIB=y CONFIG_AUDIO=y CONFIG_YM3812=y SBC_BASE=220 SBC_IRQ=10 SBC_DMA=1 SB_DMA2=5 SB_MPU_BASE=330 SB_MPU_IRQ=-1 DSP_BUFFSIZE=65536
| |