Have a look at this one.
Netalyzr
http://netalyzr.icsi.berkeley.edu/learn.html
http://netalyzr.icsi.berkeley.edu/
FAQ
http://netalyzr.icsi.berkeley.edu/faq.html
A search of Softpedia, using the keyword latency gets these, change the
keyword, if you don't find what you want.
http://www.softpedia.com/get/Network-Tools/Network-IP-Scanner/Ping-Utilities.shtml
http://www.softpedia.com/get/Network-Tools/Network-Monitoring/VE-Network-Catcher-Lite.shtml
http://www.softpedia.com/get/Network-Tools/Network-Testing/ADSL-Reporter.shtml
http://www.softpedia.com/get/Network-Tools/Misc-Networking-Tools/WildPackets-Network-Calculator.shtml
http://www.softpedia.com/get/Network-Tools/Network-Testing/CommTest.shtml
http://www.softpedia.com/get/System/System-Info/DPC-Latency-Checker.shtml
No
DNS benchmark
http://www.grc.com/dns/benchmark.htm
--
Pooh the cat
> VanguardLH wrote:
>>
>> Looking to measure DNS latency. That is, how long from when my host
>> issues a DNS request (for a lookup) to when it receives a response
>> (either the IP address or a failure).
>
> Have a look at this one.
> Netalyzr
> http://netalyzr.icsi.berkeley.edu/
Interesting and deficient results were generated by their Java tester,
which included:
- My anti-virus triggered on them attempting to download the EICAR test
file for viruses.
- "Direct TCP connections to remote FTP servers (port 21) failed." I
have no problem using ftp.exe or SmartFTP to connect to FTP sites.
- "Direct TCP access to remote SMTP servers (port 25) is prohibited."
That would be my ISP that as blocked traffic over port 25 (the old
SMTP port but clients were supposed to be using 587 since around
1999). Only MTAs are supposed to be using port 25, not by MUAs.
- "Direct TCP access to remote RPC servers (port 135) is blocked." That
is probably the Windows Firewall under Windows XP. File sharing is
enabled but port 135 isn't included in that exception. Plus my
router's firewall blocks the NetBIOS ports, too.
- "The round-trip time (RTT) between your computer and our server is 47
msec". That would be the same delay measure in the ping output,
depends on what is the slowest node in the route between me and their
server, but is not what I was looking for regarding how long for the
nameserver to accept and return a status for a DNS request.
- "The time it takes your computer to set up a TCP connection with our
server is 49 msec". That's how long to establish a socket with the
target server host. Won't include the time to process the DNS
request. So only part of the latency is included.
- "Changes to headers or contents sent between the applet and our HTTP
server show the presence of an otherwise unadvertised HTTP proxy".
Caused by using the Web Shield to interrogate my web traffic by my
anti-virus program (Avast Home). However, all other headers, even
malformed ones, still arrive okay at the target server.
- "Your ISP's DNS resolver requires 140 msec to conduct an external
lookup." TADA!!! There it is.
- "Your ISP correctly leaves non-resolving names untouched." Only
because I opted out of my ISP's redirection service on failed DNS
lookups (so none of them fail but instead their DNS server shoves back
a redirection to their search page).
Interesting testing site and Java applet. Adding it to my Favorites
list. I'll have to run it several times to get an idea of how much it
might fluctuate and over what range. Thanks for the link.
> A search of Softpedia, using the keyword latency gets these, change the
> keyword, if you don't find what you want.
I visited both softpedia.com and download.com and searched on "dns
latency". Neither came up with applicable freeware solutions. I didn't
search on just "latency" since my goal was specifically to find DNS
latency.
I found this one quite handy. I have my router's DNS server (which
pointed to my ISP's DNS server but now to OpenDNS), the OpenDNS servers,
and a couple of my ISP's DNS servers. I reduce the list just to those
in which I'm interested in using. It helped me determined how I want my
setup.
My ISP and OpenDNS uncached latency was about the same. However, cached
DNS lookups were half as long (twice as quick) as for my ISP. I had
opted out of my ISP's redirection service (for DNS lookup failures)
because I'm not interested in getting a search page if an IP name has
not lookup. OpenDNS sticks you with their redirect service (unless you
setup an account with them). However, at half the latency for cached
DNS lookups, I decided speed was more important than the occasional
redirect to OpenDNS's search page. While I don't like the redirect on a
failed DNS lookup, the rest of family thinks it's quite handy.