Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


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

ATTBI just changed DNS servers



On Fri, Nov 08, 2002 at 05:28:25PM -0500, John Abreau wrote:
> The thng about nameservers is that *everything* depends heavily 
> on them. The nameservers are the biggest factor affecting your 
> perceived response time for every interactive use you make of the 
> Internet. 

Sorry, that's not so.

In certain cases, name response is a significant factor, but it
hardly ever dominates wall-clock response time.

Let's look at some typical cases:

- ssh session: initial setup includes two DNS lookups, but total
session time is in minutes, and interactive response time is
extremely similar to single-packet round trip time on unloaded CPUs.
On heavily loaded CPUs, CPU time dominates.

- file transfer: initial setup includes one, possibly two DNS lookups,
but even a 1MB file over an uncongested cable modem link takes on the
order of 8 seconds. Larger files or slower links decrease DNS's
contribution. Doesn't really matter whether this is streaming or
prerecorded.

- remote desktop control: again, no DNS lookups after the session is
established, and sessions vastly outlast setup.

- any non-netcentric application, used remotely: just like a remote
desktop control scenario.

- web surfing: here's the first case where DNS resolution time looks
like it might be a factor, and in fact it is. Each page loaded requires
a minimum of one DNS lookup, and often several: text from one server,
graphics from another, advertising from two more, and database lookups
from a sixth. However, every modern browser has a built-in DNS cache to
alleviate such problems, so subsequent requests to the same servers do
not incur that penalty.

Still, having a local DNS cache is almost always a win, just not a
particularly huge one. There's no reason not to have nearly every
desktop, and certainly every small network, so equipped.

-dsr-




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org