Our one blocker bug hasn't yet been stomped, but it's been cornered. We
now understand much more about the problem.
It was introduced by Hal's attempt to clean up DNS handling for pool
queries on May 14th. It seems to affect only pool queries - I don't
think it can bite if you give an explicit s
Background:
This isn't related to the bug, but often adds a layer of confusion when
trying to understand what is going on with DNS. The old ntpq -p had a few
lines of code that skipped some entries. I forget the details. I think it
skipped slots that hadn't received any responses yet.
I ma
I think it's important to split work on this into several areas.
The first is the simple no-DNS (and hence no-pool) case. This is the
important case.
How long does it take to get started when ntp.conf has 3 or 4 server slots
specified by IP Address? The interesting case is using iburst, but
Hal Murray :
>
> I think it's important to split work on this into several areas.
>
> The first is the simple no-DNS (and hence no-pool) case. This is the
> important case.
>
> How long does it take to get started when ntp.conf has 3 or 4 server slots
> specified by IP Address? The interesti
