Endless Health Check on OS X Lion

[GoogleCodeExporter]

After Namebench did initial health check on 411 servers, it just started from 
#1 again.

Original issue reported on code.google.com by reakt...@gmail.com on 31 Jul 2011 at 10:53

[GoogleCodeExporter]

Thanks for the bug report. I don't have a machine running Lion yet to try to 
replicate the issue on. I suspect this is already fixed by the threading 
changes in the namebench 1.5 code, but I have not yet connected the UI to the 
code base.  I will try and get a beta together soon. 

Original comment by helixblue on 31 Jul 2011 at 3:38

• Changed state: Accepted

[GoogleCodeExporter]

In case it makes a difference, the Console does log what is going on. I can't 
for the life if me find where the actually file on disk is that NameBench is 
logging to, so it must just log to the console only.

Here is a pastebin of the log lines: http://pastebin.com/x5Kmraf0 ( 2925 before 
I gave up. I let it run overnight )

Each line has two lines, if you expand the logging triangle:
9/7/12 11:02:23.662 AM 
namebench[12046]: Waiting for wildcard cache queries from 22 servers (22 
threads) [0/22]

Running from the command line seems to work, under certain cases.
Here is my path: 
$echo $PATH
/Users/me/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin

python is in that path: 
$which python
/usr/bin/python

This will then fail:
$./namebench.py -s all
Usage: namebench.py [options]

namebench.py: error: option -s: invalid integer value: 'all'

Taking away the -s flag and it still fails:  I have to call the full path:
$/usr/bin/python namebench.py

This is version 1.3.1

* For me results are inconsistent from the GUI to the CLI.  I have an older 
10.6 machine I ran the GUI version on. I also ran the CLi version there.  This 
machine is an old Mac Mini that was doing nothing.  The GUI will always tell me 
that Comcast San Jose is ~17% faster, the CLI will always say:
DynGuide         ##################################### 33.56

In the end, neither of them feel as fast as the good old 8.8.8.8.  Perhaps that 
is that the other NS's are faster for first time lookups, but my use case has 
me hitting common urls that someone the size of google has cached already Adan 
I will never beat that advantage.  Yet oddly, I turned on BIND/named on a 3rd 
machine, and it was the fastest of the all, and had not been used as an NS for 
recursive lockups at all.  That NS blows them all away with sub 5ms lookups on 
everything.

CLI results: http://pastie.org/4683653 of one of my many tests.  Both pastbin 
and pastie have issues with these large amounts of data.  I was only able to 
use paste, and even then seeing the results would show a grey screen at the 
bottom half of the data.

Original comment by sc...@newgeo.com on 8 Sep 2012 at 4:37

Attachments:

• NameBench-results.txt