web browsing extremely slow

[Mikel Ward]

I just tried to install the Intrepid RC.

Near the end of the install, it said "Configuring apt": "Scanning the mirror...", and did this for between 3 and 5 minutes.

After the install finished, I opened up Firefox to browse the web, and it was painfully slow.

After I experienced the slowness, I tried pinging some sites, and they responded quickly.

After I rebooted into Windows, everything was working fine.

My ISP has no known issues around this time.

I have an nVidia-based mainboard with a Realtek RTL8168B network card on a Cat5/Fast Ethernet network (IPv4 only) with an ADSL2+ Internet connection.

[Mikel Ward (mikelward)]

Possibly related to module-init-tools bug 9100 (https://bugs.launchpad.net/ubuntu/+source/module-init-tools/+bug/9100/).

My DNS server is a Netgear router that doesn't support IPv6.

Will reboot and check.

[Mikel Ward (mikelward)]

Firefox is the wrong package. Things like apt are affected too.

I tried adding ipv6 to the modules blacklist and rebooting, but it still occurred.

/etc/resolv.conf is correct. tcpdump shows no request for IPv6 AAAA records and shows the DNS server responding quickly.

Possibly even a network driver bug?

[Mikel Ward (mikelward)]

Changing the MTU on eth0 down to 1428 made things work.

Definitely not a bug in Firefox. :-)

[Mikel Ward (mikelward)]

The network card is a Realtek 8168b according to the output below.

Assume it's an issue with the kernel driver (r8196), some general network support in the kernel, or less likely an issue with NetworkManager.

Note that this is the first time I've ever had to set an explicit MTU.

[ 2.612130] eth0: RTL8168b/8111b at 0xf88b2000, 00:18:f3:0e:cf:9d, XID 38000000 IRQ 221
[ 25.421075] r8169: eth0: link up
[ 25.421099] r8169: eth0: link up

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
 Subsystem: ASUSTeK Computer Inc. Device 81aa
 Flags: bus master, fast devsel, latency 0, IRQ 221
 I/O ports at ee00 [size=256]
 Memory at fdbff000 (64-bit, non-prefetchable) [size=4K]
 [virtual] Expansion ROM at fdf00000 [disabled] [size=128K]
 Capabilities: [40] Power Management version 2
 Capabilities: [48] Vital Product Data <?>
 Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+
 Capabilities: [60] Express Endpoint, MSI 00
 Capabilities: [84] Vendor Specific Information <?>
 Capabilities: [100] Advanced Error Reporting <?>
 Capabilities: [12c] Virtual Channel <?>
 Capabilities: [148] Device Serial Number 68-81-ec-10-00-00-00-1a
 Capabilities: [154] Power Budgeting <?>
 Kernel driver in use: r8169
 Kernel modules: r8169

# uname -r
2.6.27-7-generic

[Mikel Ward (mikelward)]

It may also be related to bug 59331 and http://kerneltrap.org/node/6723.

[Mikel Ward (mikelward)]

The optimal MTU was 1492. Anything higher would fail.

It turns out my ADSL router was configured with an MTU of 1500, but should have been set to 1492.

For some reason (I'm assuming a poorly designed router), ping with don't fragment and a fixed packet size didn't reveal this.

With eth0 mtu=1500, ADSL mtu=1500, ping -M do -s 1470 www.slashdot.org just hangs. With eth0 mtu=1500, ADSL mtu=1492, it prints lines like this:
From www.routerlogin.com (192.168.1.254) icmp_seq=2 Frag needed and DF set (mtu = 1492)

So setting my ADSL modem's MTU to 1492 appears to be the correct fix, but it does make me wonder why CentOS 5, NetBSD, and Windows have all been working fine, all connected via Ethernet.

[Alexander Sack (asac)]

is this a ppp connection?

[Alexander Sack (asac)]

are you using network-manager? What kind of connection is that? do you use a router at home or go directly through something like pppoe?

[Mikel Ward (mikelward)]

Ethernet card onboard my ASUS mainboard plugged into a local network. Other end of the network is an all-in-one wireless router with inbuilt ADSL2+ modem. From the perspective of my PC, it's all just plain Ethernet.

eth0 =CAT5= router-ADSL modem =phone line=

I'm using NetworkManager, but I don't think it's the cause of the problem here. More likely the Linux kernel not dynamically varying the maximum segment size (MSS) based on my limited understanding. (And probably something that changed after Linux 2.6.18.)

[Morris Jones (mojo-whiteoaks)]

This problem remains in 9.04 desktop.

I installed to a desktop machine connected to DSL via a NAT router.

The first effect of the wrong MTU (1500) was an extremely slow installation during the process of scanning for updates. After the install finally completed, Mozilla would appear to connect to sites, even a server on my local network, but not deliver any pages.

The odd exception was Google. I could connect to Google and get search results, but not browse any directed pages.

This report had the solution I needed -- change the MTU to 1492. (What a difference eight bytes makes.)

I'm not familiar with the mechanism the installer uses to set an initial MTU value, but it would be a major improvement to have it install with a working default. The worst part is that the problem is so difficult to diagnose without prior knowledge. This has a major impact on the user experience for a new installation.

[dsiddens (sv-drakus)]

In my case I'm using a Thinkpad 43p, 2GB, and Ubuntu 9.04. The dowload speeds, as reported by Ubuntu's System Monitor runs in the 20 to 80 Kb/s. Mostly around 35Kb/s. The ISP (Century Link) sent out a tech and the he reported that the line was good (above a minimum of 9Mb/s. We actually were getting slightly above 11Mb/s. We tried three other computers all of which were running some issue of Windows XP. The XP machines all clocked above 9Mb/s using Speakeasy.net.

I just ran another speed test and compared the result to the Ubuntu System Monitor: While the external site said about 54Kb/s, System Monitor reported about 12Kb/s.

Doug

[Launchpad Janitor (janitor)]

[Expired for network-manager (Ubuntu) because there has been no activity for 60 days.]