[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Debian-NYC] debugging network slowness [was: Thanks for yesterday!]



Hi Daniel,

OK reporting back to you from Windows 7:



   DNS Servers . . . . . . . . . . . : 192.168.2.1
                                       208.59.247.45
                                       208.59.247.46


and the DNS info from Debian  :


nameserver 192.168.2.1
nameserver 208.59.247.45
nameserver 208.59.247.46

So both are the same

And now for the time info:

time dig tshort @208.59.247.45 nytimes.com 199.239.136.200

( cut and pasted the relevant info I hope )

real    0m0.125s
user    0m0.016s
sys    0m0.008s


And the next bit of time info:


time dig tshort @208.59.247.46 nytimes.com 199.239.136.200



real    0m0.042s
user    0m0.020s
sys    0m0.012s


and with Google public DNS:


time dig tshort @8.8.8.8 nytimes.com 199.239.136.200


real    0m0.153s
user    0m0.016s
sys    0m0.012s



So, I must admit that this is a bit in the deep end for me but we are getting roughly all the same info...

what does this mean?

Thanks!

Steve

On Fri, Dec 3, 2010 at 1:14 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
Hi Steve--

I think you have some problems with your DNS resolver, and maybe
problems with your network connection as well.  Here's why:

On 12/02/2010 08:22 PM, steve beltzer wrote:
> Here is mine without the q:
>
>  time wget -O/dev/null nytimes.com
> --2010-12-02 20:13:04--  http://nytimes.com/
> Resolving nytimes.com... 199.239.136.200
> Connecting to nytimes.com|199.239.136.200|:80... connected.
> HTTP request sent, awaiting response... 301 Moved Permanently
> Location: http://www.nytimes.com/ [following]
> --2010-12-02 20:13:19--  http://www.nytimes.com/

note the gap between the two timestamps above: 15 seconds just to look
up the domain name "nytimes.com" and get an HTTP 301 redirect from the
server!

> Resolving www.nytimes.com... 170.149.173.130
> Connecting to www.nytimes.com|170.149.173.130|:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: unspecified [text/html]
> Saving to: “/dev/null”
>
>     [     <=>         ] 131,294     17.8K/s   in 7.2s

so the actual data transfer took 7.2s, which is more than it should be
too -- this is what makes me suspect a network problem.

> 2010-12-02 20:13:42 (17.8 KB/s) - “/dev/null” saved [131294]
>
>
> real    0m37.927s
> user    0m0.000s
> sys    0m0.020s

and the total real time was probably about 15 seconds for the first DNS
lookup (nytimes.com) + 15 seconds for the second lookup
(www.nytimes.com) + 7 seconds for the data transfer == 37s

In your message to Lee, you said your list of nameservers was:

nameserver 192.168.2.1
nameserver 208.59.247.45
nameserver 208.59.247.46

So maybe the next step would be to try querying those nameservers
directly (and maybe other nameservers?) to see which ones are timing out?

> With Windows 7 I can see the NYTimes logo nearly instantly and the page is
> loaded w the adds and the NYTimes video within like 15 sec...

I'd be curious to know what DNS resolvers (nameservers) your Win7
install is using.  if you boot into windows 7, i think you can get this
by opening a command prompt (Start Menu → Run... → "cmd") and running:

 ipconfig /all

(this could be entirely wrong for Win7, i'm afraid -- i haven't used
windows in ages)

somewhere in the ipconfig output, i think it lists DNS resolvers under
the heading "DNS Servers" -- what does that say?



Back to debian, you can time queries to your various resolvers like this:

0 dkg@pip:~$ time dig +short @208.59.247.45 nytimes.com
199.239.136.200

real    0m0.043s
user    0m0.004s
sys     0m0.008s
0 dkg@pip:~$

Try that on all the DNS resolvers that the two operating systems list --
do you see what part of the above command to change to make it query a
different server?  Try also against google's public DNS resolver, which
has IP address 8.8.8.8 and should be available 'net-wide.

What you're looking for is whether any of the servers are particularly
slow (or entirely unresponsive).  If we can narrow it down to a faulty
nameserver, then we can take the next step of figuring out why the
faulty nameserver is showing up in the first place and fix that.

If they're *all* slow, then it seems likely to be a network problem pure
and simple, which would point us down a different debugging path.

Make sense?  Report back!

       --dkg

PS you've been seeing a bunch of command-line examples here, because
they are useful, repeatable, easily-documentable ways to use the
computer.  If you're interested in learning more about the command line
(and bash in particular, which is the default user shell on debian
systems), i recommend FLOSS Manuals' "Introduction to the GNU/Linux
command line" as a good way to get up to speed:

  http://en.flossmanuals.net/gnulinux


_______________________________________________
DebianNYC mailing list
DebianNYC@vireo.org
http://lists.vireo.org/cgi-bin/mailman/listinfo/debiannyc


_______________________________________________
DebianNYC mailing list
DebianNYC@vireo.org
http://lists.vireo.org/cgi-bin/mailman/listinfo/debiannyc

Reply to: