I have what I think is a typical home & home office LAN:

• cable-based ISP
• cable modem with wire ethernet port
• modem port conx to wireless access point and switch
• switch provides DHCP and gateway router
• house LAN switch conx gateway switch
• all switches are 100baseT
• all wifi is 802.11n

Therefore, my laptop has a wifi link to the access point and a hop from the A/P to the cable modem and a hop from the cable modem to THE NET.

Sometimes things run really well. Sometimes I need adult beverages and knitting. I suspect some troubles with name services offered by my ISP -- they are notoriously sloppy. How do I discover what is taking so much time as I browse the net?

I understand that a browser request involves a DNS lookup and connect request followed by a fetch, page load and render.
I understand that a page load might have a basket full of other DNS requests for whatever is on the page at hand.

How do I discover if I have a DNS problem? If so, how do I resolve this trouble?

I understand that the page render depends on my browser of choice (Firefox 3.0.18) and all of the multi-whatever happening on my laptop (Ubuntu Jaunty on Core2Duo and 4 GB ram).

I know how to deal with busy box issues.

Is there some way to discover what is happening without the arcane magic of a LAN traffic analysis, spectrum analysis, time-domain reflectometry and all that smoke and mirrors?

Wishing and hoping for clues from my august community colleagues and mentors.

Thanks,
~~~ 0;-Dan

Wireshark may help your search.

Your recommendation for adult beverages is noted; I am less sure about the benefits of knitting, but whatever works for you.

several things here, depending on whether you really want to measure carefully, cogitate and then make changes and measure again...or just jump in and try stuff, but:

• measure how well (or not) nameserving is actually working
• use dig; look at times taken; is it long (200mS would be bad), does it sometimes takes much longer than usual?
• usually, boxes like routers have an ability to run a small DNS lookup cache (& I do mean small - not many entries); are you using that?
• alternatively, you can run your own explicit lookup cache (imho, BIND is massive overkill for this; DNSMASQ or DJBDNS are more sensible)
• you can measure DNS performance; In the past I have tried two utilities for this; one is a windows program that runs nicely under wine (and has good graphics) and one is native; I can't recall the exact names of which is which but look here and here
• you might then choose to change your name service; I can say that openDNS does work, it may not be the absolute fastest, but it seems never to be terribly slow

in general, opera is faster (except for java or javascript in one of which it is slow, but the next release is supposed to fix that), but if you like firefox, work with that. But you could increase the size of the cache on whichever browser that you choose.

are you saying that you are using busybox, or something else

The good part is that "spectrum analysis, time-domain reflectometry and all that" wouldn't actually help you. LAN traffic analysis, however...

I keep forgetting, and getting slapped as a reminder, that most words and phrases have been appropriated somewhere in the geekish or technobabble lexicon.

When I said, "busy box" I meant that literallly == a "box" [meaning workstation or laptop or computer system] that is "busy" [meaning working very hard doing something including but not limited to useful work on my behalf (as opposed to eye candy or other background cycle consumption)].

Years ago, I worked on a mainframe that had a "class scheduler". One built a table of application programs -- something that could be runnable -- and assigned them to named classes. One then assigned each class some percentage as a "run time quota of sorts". The scheduler did its normal things but tried to keep each class within it quota. One could limit "eye candy" to 10% or similar. But I digress...

~~~ 0;-Dan

...and I should have added, even though you didn't ask, that anything to do with ipv6 should be firmly off.