Cannot compile on Windows 7 64 bits with Visual Studio 2013 community.
Eric S. Raymond
esr at thyrsus.com
Fri Jan 1 07:06:27 UTC 2016
Hal Murray <hmurray at megapathdsl.net>:
> > With a little work (a simple enough job that I don't need to be the one to
> > do it, I think) it should be possible to change the --disable-dns-lookup
> > option to always use synchronous lookup on hostnames, so the IP-only
> > restriction is removed at the cost of a small amount of startup lag.
> I think you are confusing things by thinking of it as a startup problem.
OK, the places where I made asynchronous lookups an option are on
command line and config-file hostames.
> The pool stuff also does DNS lookups and those may happen at non-startup time.
Right, I do tend to forget about that case.
> Even if startup works, I'd like to be able to occasionally (say daily) use
> DNS to verify that the server is still in the pool. That's a long-term
> project. Something like that would also be useful to verify that a
> (non-pool) server hadn't moved.
> I agree that it's worth investigating using synchronous DNS. I expect it
> will work fine on a lightly loaded system which covers most of the systems
> running ntpd.
> On the other hand, I think we should be able to make a clean threaded
> version. Don't get fooled by the current code. It's not an inherently hard
> problem. A good example might be useful for other projects.
Maybe. This is me looking for complexity reductions; important part of my job.
> > Later, after I deliver replay, I'm going to do a bunch of profiling. I'm not
> > actually convinced that the async-dns code is worth its complexity cost in
> > avoided startup lag, and I mean to measure the difference over a large
> > number of runs to find out.
> I think that will be misleading on several counts.
> The question is not what is the average time, but rather what is the worst
> The performance in your environment may not tell you much about my
You are certainly right on the first count, but I question the second.
I believe the cost of synchronous lookups is dominated by WAN latency
rather than the local system's performance, and I think those
latencies have dropped a lot in the last decade. Instead of
theorizing I want to *look*.
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
More information about the devel