# DNS sloooooowwwww.....

## Kezza

I'm a newbie to Linux and love Gentoo but am a little disappointed in Internet performance. I'm sure something is not configured correctly.

Using my dialup internet connection under Linux seems a lot more sluggish under Linux than under Windows on my PC (P4 2GHz, 768MB, Ext 56k modem on ttyS0). Under windows web-pages visibly begin to be loaded within 1s of typing in the URL; under Linux web-pages visibly begin to be loaded after 3-4s.

Ping times are as follows:

Linux:

```

bilbo@shire ppp # ping 203.97.33.14

PING 203.97.33.14 (203.97.33.14): 56 octets data

64 octets from 203.97.33.14: icmp_seq=0 ttl=249 time=188.3 ms

64 octets from 203.97.33.14: icmp_seq=1 ttl=249 time=150.7 ms

64 octets from 203.97.33.14: icmp_seq=2 ttl=249 time=170.0 ms

64 octets from 203.97.33.14: icmp_seq=3 ttl=249 time=151.1 ms

64 octets from 203.97.33.14: icmp_seq=4 ttl=249 time=151.4 ms

64 octets from 203.97.33.14: icmp_seq=5 ttl=249 time=140.1 ms

64 octets from 203.97.33.14: icmp_seq=6 ttl=249 time=140.7 ms

--- 203.97.33.14 ping statistics ---

7 packets transmitted, 7 packets received, 0% packet loss

round-trip min/avg/max = 140.1/156.0/188.3 ms

```

and under Windows:

```

C:\Documents and Settings\bilbo>ping 203.97.33.14

Pinging 203.97.33.14 with 32 bytes of data:

Reply from 203.97.33.14: bytes=32 time=111ms TTL=249

Reply from 203.97.33.14: bytes=32 time=109ms TTL=249

Reply from 203.97.33.14: bytes=32 time=113ms TTL=249

Reply from 203.97.33.14: bytes=32 time=109ms TTL=249

Ping statistics for 203.97.33.14:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 109ms, Maximum = 113ms, Average = 110ms

```

Admittedly, the ping times are not significantly different, but the difference in browsing quickly becomes very significant. Here's a few random examples to illustrate (times are from hitting enter after typing in URL to web-page is fully loaded):

	www.gentoo.org  17s under Windows; 47s under Linux

	www.toyota.com  22s under Windows; 105s under Linux

	www.blackboard.scs.vuw.ac.nz  4s under Windows; 12s under Linux

(I cleared/disabled the browsing cache prior to ensure a more accurate comparison)

Also polling for mail is far more slow under Linux.

Searching the net and forums have allowed me to try the following (all without success)

1) Changing the order of the entries in /etc/resolv.conf has no effect whatsoever on ping times or browsing performance.

2) setserial -a /dev/ttyS0 and then checking in /proc/interrupts established there are no conflicting IRQs

3) I lowered the modem speed in /etc/ppp/options from 115200 -> 57600 - this caused performance to slightly decrease

4) MRU/MTU settings are the same as in windows

I'm now at a real loss. Any advice would be most appreciated.

----------

## slyzer

Hi,

that's a 'feature' of the Internet Exploder. There was an article at slashdot a while ago. IE ignores the TCP standard so he loads faster. Try to search at slashdot it was explained very good  :Smile: 

cu

 slyzer

----------

## kerframil

Two thoughts spring to mind:

1. Ensure that the modem is initialised with the same sequence of AT commands before the dial-up operation occurs. You can get this from the .inf file (which is the Windows driver), or by running something like portmon from http://www.sysinternals.com and sniffing the traffic to your serial port. These commands could affect performance

2. How are you specifying your DNS servers? Make sure you allow DHCP to choose them, because many ISPs have more than two DNS servers and assign different ones according to which dial-up pool you end up being a part of.

I believe also that Windows 2000 and higher use a client-side DNS resolver cache (as evidenced by the presence of the ipconfig /flushdns command). You may want to configure bind or djbdns as a cacheing-only nameserver for a fair comparison because, AFAIK, the Linux DNS resolver routines don't have this functionality by default. I have also found that sometimes (rarely, but sometimes) the core Internet root DNS servers perform better than those of one's ISP (this presently seems to be the case with my cable service). If you run a cacheing server, the proximity of the DNS server becomes slightly less important - particularly if you regularly visit the same sites or hosts.

Of course, there could be several other factors at play here but maybe the above will provide a lead.

EDIT: it occurred to me that as you used an IP address for your ping tests, DNS has little to do with it; at least not tests involving ICMP packets anyway.Last edited by kerframil on Thu Feb 06, 2003 10:50 am; edited 1 time in total

----------

## kerframil

 *Quote:*   

> IE ignores the TCP standard so he loads faster.

 

Even if there is any merit in that, it doesn't explain a difference in ping metrics.

----------

## krt

as goofy as this sounds - compare the init strings Windows is sending to your modem and what init strings Linux is sending to them.. I'm willing to bet that Linux is sending out things for a generic setup, whereas Windows is sending out strings for your specific modem.  This has the potential for a big difference in what you get from your modem.  In addition to that, compare your specific dialup protocol settings.  Linux PPP might be escaping a lot of characters, whereas Windows might not be .. 

What you're looking for is anything that can cause 1) A different form of handshake in terms of the modems operating, and in terms of how the modem handles line rates after the hand shake (all set by init strings, usually) and 2) Anything that will cause protocol overhead, such as escaped character sequences, lack of compression when compression is supported, etc.

----------

## slyzer

 *kerframil wrote:*   

>  *Quote:*   IE ignores the TCP standard so he loads faster. 
> 
> Even if there is any merit in that, it doesn't explain a difference in ping metrics.

 

That's right, but IE is much faster while he's ignoring some TCP signals. The ping time is one factor but the IE-'faster-load-feature' another, I think.

cu

 slyzer

----------

## zhenlin

I think this is a mozilla 'feature'. If he is using mozilla. Mozilla has a rendering delay, which I still have no idea what for.

----------

## kerframil

 *zhenlin wrote:*   

> If he is using mozilla. Mozilla has a rendering delay, which I still have no idea what for.

 

If you're comparing Mozilla to IE in terms of potential speed differentials, this is a good point. But the rendering delay is just that, a rendering delay. It's got nothing to with either TCP/IP bandwidth or latency and doesn't explain a differential of 83 seconds for loading a single web page. For toyota.com to take 105 seconds to load seems absurd - the page isn't even that heavy. He is clearly not getting the kind of speed you would expect.

The rendering delay is to prevent Mozilla from displaying page content too early (before the page has been loaded and therefore can be correctly layed out), therefore incurring overhead as the page content is re-arranged. This can be reduced (not always safely) but IMO a well-compiled Mozilla on a well-configured system generally outdoes IE, especially with HTTP 1.1 and pipelining enabled. Once loaded, Mozilla on Windows outperforms IE in the general to the point where even inexperienced users notice, whether or not IE uses the TCP nodelay option (or whatever the feature is that slyzer refers too).

My point is basically, this seems to be primarily a question of TCP/IP and PPP. There is no good reason why the latency (or bandwidth) should be any lower than that of his Windows stack. I suggest that TCP/IP kernel options, modem init strings (as already discussed) and PPP options are a good place to start.

Kezza, have you also tried playing with some of the setserial options, such as baud_base (maybe that isn't being set to 115200 as it should be) or low_latency? The kernel auto-configures the serial port by default, maybe you should try manually configuring it. Also what kernel are you using? Have you tried a vanilla kernel, just to make sure it's not an adverse effect of using a heavily patched kernel? That sort of thing is worth ruling out.

----------

