s34n: yes I have. while konqueror (sometimes) seems marginally faster than mozilla, that does not at all solve the issue of >30sec waits for contacting some sites.

alxdotnet: I will definately check this out. there are options to turn IPv6 support on/off when compiling a kernel. IIRC it is recommendet to turn it on, which is why I didn't think this should have a major impact on performance (at least not negative ).

Thanks janW! I just remember hearing something about IPv6 and performance before, and I know you can configure it in the kernel setup, so I'd be interested in knowing if turning it off fixes the problem. It'd make sense, since from what I've read it's off in 2.4 by default.
-Alex

*edit* does anyone have 2.6 with fast internet?

Interesting...I installed Mozilla and it's doing much better. While it takes 20 seconds or so to establish initial contact, loading pages within that domain is near instantaneous. Still, it doesn't beat 2.4.

Come on pplz, let's solve this!
On my Mandrake 10.0, the shell command "lynx linuxquestions.org" takes 20 seconds to execute and display a page.
The command "ping linuxquestions.org" responds like this:
[alxdotnet@ALEX alxdotnet]$ ping linuxquestions.org
PING linuxquestions.org (64.179.4.146) 56(84) bytes of data.
64 bytes from linuxquestions.org (64.179.4.146): icmp_seq=1 ttl=45 time=71.9 ms
64 bytes from linuxquestions.org (64.179.4.146): icmp_seq=2 ttl=45 time=67.7 ms
64 bytes from linuxquestions.org (64.179.4.146): icmp_seq=3 ttl=45 time=66.7 ms
64 bytes from linuxquestions.org (64.179.4.146): icmp_seq=4 ttl=45 time=67.2 ms

The response is instantaneous. However, if i "lynx 64.179.4.146", lynx responds instantaneously! This is confusing me!
Apparently the DNS lookup is causing the problem, but how come ping is able to do it instantly and lynx takes forever? What's the difference? Come on, let's solve this thing!

Have you tried to turn off IPv6? I am fighting the same problem with Mandrake 10, ping times are good download speeds are good, surfing speeds are horible. I am willing to try about anything.

After further research I found this http://www.linuxquestions.org/questi...hreadid=158683 I will try it tonight.

This line reduced the time for me from about 20 seconds to 3~7 (at any given site).

EDIT:

I just went to Mandrake Control Center, Network / Internet, Manage Connections. I found that my connection was set to static, and I have DHCP... this confused me so I changed it to DHCP. Sites load -MUCH- faster now....

EDIT 2:

Don't do it though because now I can't even load my control panel, lol. Great...

EDIT 3:

Restarted, works great and everything is awesome like 2.4!

Weird. Problem fixed itself.
Actually, strange as it may sound I think it had something to do with the KDE theme I was using. I switched to Keramik and response time fell to zero. Oh well, at least it works now...

It doesn't seem to fix itself on my box. And the "alias net-pf-10 off" in /etc/modules.conf didn't fix it either.

As mentioned before, I have the choice of recompiling a kernel (2.4 or 2.6) and having fast internet but a slow SATA harddrive, or use the Mandrake kernel and have a fast harddrive and slow internet. I just switched to the former (deactivating IPv6 support). I'll see what I can do about the SATA driver.

Anyway, the bottom line is that recompiling the kernel without IPv6 support fixes my problem with the slow internet (2.4 or 2.6, both work).

JanW

The only other thing I recall doing is changing my DHCP client....

Hello everybody.

I have the same problems using Mandrake 10.0 with the 2.6.3-4 Kernel:
- Incredibly slooooooooow surfing, despite DSL-connection (1,5MB/s down, 256kb/s up)
- Faaaast downloads (up to 150kb/s)

What seems to slow the process down is the DNS-resolving which of course doesn't occur during a longer Download. I have a Realtek PCI Ethernet card and use the standard rtl8139 driver. I DON'T think it's a device/driver issue. Besides I noticed an actual 'flood' of shorewall-messages in my syslogs. I don't know wheater this is just some kind of a debugging feature in the pre-version of 10.0, but anyhow I'm interested in turning this off :D Guess I'll have to change the iptables? Oo

-- syslog-excerpt:
Mar 30 22:28:08 dorsch kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC= SRC=192.168.0.11 DST=192.168.0.255 LEN=139 TOS=0x00 PREC=0x00 TTL=64 ID=338 DF PROTO=UDP SPT=631 DPT=631 LEN=119
Mar 30 22:28:39 dorsch kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC= SRC=192.168.0.11 DST=192.168.0.255 LEN=139 TOS=0x00 PREC=0x00 TTL=64 ID=340 DF PROTO=UDP SPT=631 DPT=631 LEN=119
Mar 30 22:29:10 dorsch kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC= SRC=192.168.0.11 DST=192.168.0.255 LEN=139 TOS=0x00 PREC=0x00 TTL=64 ID=342 DF PROTO=UDP SPT=631 DPT=631 LEN=119
Mar 30 22:29:41 dorsch kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC= SRC=192.168.0.11 DST=192.168.0.255 LEN=139 TOS=0x00 PREC=0x00 TTL=64 ID=344 DF PROTO=UDP SPT=631 DPT=631 LEN=119
Mar 30 22:30:12 dorsch kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC= SRC=192.168.0.11 DST=192.168.0.255 LEN=139 TOS=0x00 PREC=0x00 TTL=64 ID=346 DF PROTO=UDP SPT=631 DPT=631 LEN=119
Mar 30 22:30:43 dorsch kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC= SRC=192.168.0.11 DST=192.168.0.255 LEN=139 TOS=0x00 PREC=0x00 TTL=64 ID=348 DF PROTO=UDP SPT=631 DPT=631 LEN=119
Mar 30 22:31:14 dorsch kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC= SRC=192.168.0.11 DST=192.168.0.255 LEN=139 TOS=0x00 PREC=0x00 TTL=64 ID=350 DF PROTO=UDP SPT=631 DPT=631 LEN=119
Mar 30 22:31:45 dorsch kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC= SRC=192.168.0.11 DST=192.168.0.255 LEN=139 TOS=0x00 PREC=0x00 TTL=64 ID=352 DF PROTO=UDP SPT=631 DPT=631 LEN=119
Mar 30 22:32:16 dorsch kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC= SRC=192.168.0.11 DST=192.168.0.255 LEN=139 TOS=0x00 PREC=0x00 TTL=64 ID=354 DF PROTO=UDP SPT=631 DPT=631 LEN=119
Mar 30 22:32:47 dorsch kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC= SRC=192.168.0.11 DST=192.168.0.255 LEN=139 TOS=0x00 PREC=0x00 TTL=64 ID=356 DF PROTO=UDP SPT=631 DPT=631 LEN=119
Mar 30 22:33:18 dorsch kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC= SRC=192.168.0.11 DST=192.168.0.255 LEN=139 TOS=0x00 PREC=0x00 TTL=64 ID=358 DF PROTO=UDP SPT=631 DPT=631 LEN=119
(yep, just 5 minutes... my logs are flooded with this shi*)

-- iptables -L excerpt:
Chain net2all (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
newnotsyn tcp -- anywhere anywhere state NEW tcp flags:!SYN,RST,ACK/SYN
common all -- anywhere anywhere
LOG all -- anywhere anywhere LOG level info prefix `Shorewall:net2all:DROP:'
DROP all -- anywhere anywhere

Aaaaany hint would be appreciated :)

Greets from Cologne, Germany
- Niels 'dePOLL'

Oh, and by the way: Ping times are good, but resolving the IP when pingin bla.bla is horribly slow anyway
(or at least there is a laaag between "PING bla.bla (x.x.x.x) 56(84) bytes of data." and the first row of results)

Hey, if anyone's still following this thread...
Are you accessing the internet from behind a router? From what i've gathered, the slowness is because some router/proxy/firewall is not allowing v6 packets through, and it takes 20 secs or so for the operation to time out and the DNS resolve to start again with IPv4. I am using a Dell Truemobile 2300 router.

Adding the disable v6 line above to /etc/modules.conf solved it for me.

I do have a firewall set up. And knowing next to nothing about firewall configuration I can easily believe that something's wrong there. Other than that, I'm not using a router on my end. I don't know if my ISP has maybe troubles with IPv6?

JanW

im pretty sure i have ipv6 disabled, but im having the same problem described in this thread. im using kernel 2.6.1, and access the internet from my school, which i know is a fast connection. any suggestions are GREATLY appreciated.

First thanks to everybody who tries to help us. Unfortunately the problem still isn't solved.. I added 'alias net-pf-10 off' to my modules.conf and the situation may have increased a bit, but surfing the web still is incredibly slow..

Btw, a "ipv6" module is loaded: 'ipv6 232352 10'
Dunno if this is important..