Fwd: smoketest #6 of cerowrt is go for testing

[Dave Hart]

On Sun, Jul 17, 2011 at 12:34 UTC, Dave Taht <dave.taht at gmail.com> wrote:
> On Sat, Jul 16, 2011 at 10:35 PM, Dave Hart
> <davehart_gmail_exchange_tee at davehart.net> wrote:
>>
>> On Sun, Jul 17, 2011 at 00:02 UTC, Rick Jones <rick.jones2 at hp.com> wrote:
>> > If you configure ntpd with bare IP addresses rather than names, will the
>> > getaddrinfo() return without attempting any DNS in the first place?
>>
>> Yes, basically.  ntpd might not even call getaddrinfo() in that case
>> (it may use inet_pton() or similar to convert the IP address to binary
>> representation).  At any rate, using only numeric IPv4 or IPv6
>> addresses will avoid any DNS lookups.
>
> While there is one group that is finally providing ntp time via anycast -
> which is a good solution to a large extent! - there is only the one (small)
> group doing so, rather than the needed '3'.
>
> http://news.ntppool.org/2011/03/expanding-the-anycast-dns-serv.html

You misread the announcement:  What is anycast is the DNS service for
pool.ntp.org provided by (among others) a.ntpns.org, which is the
anycast IP now served from 3 sites.  Anycast is being used to spread
the load of the custom DNS server software used for *.pool.ntp.org.
NTP time service is not being anycast by the pool operators.

I do know of one operator who provides NTP time service over anycasted
IP addresses, but it is not a good solution in general.  For simple
clients it makes no difference, but for full NTP, a single IP address
is assumed to represent a single oscillator reached via a single
network path.  ntpd keeps an eight-deep history for each configured
server of the delay, root dispersion, and apparent offset.  NTP's
clock filter algorithm chooses the lowest-delay sample from this
history, which helps remove the majority of error caused by network
delay variation -- the lowest delay sample represents the best guess
at the actual path round-trip time.  Using an anycast IP address as a
ntpd time source violates the assumption and results in samples from
more than one oscillator reached via more than one path being compared
as if they represented a single clock and path.

> And I'm reluctant, given the sordid history of hard coding ntp IP addresses,
>
> http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse
>
> to hard code *any* until far more anycast servers are online.

If you are using well-behaved NTP clients and reasonable
configurations, each server can handle many thousands of clients, each
of which is polling every 1024 seconds once settled in.  For
bootstrapping, where you need to set the time in order to enable
DNSSEC in order to enable normal operation using pool.ntp.org, you can
reasonably get by with a handful of hardcoded NTP server IPs, assuming
you are doing a one-shot NTP query during startup then switching to
DNS and pool.ntp.org for ongoing clock sync.

> To take a step backwards on this, there are extensive notes on the circular
> dependencies between time and dnssec logged here.
>
> http://www.bufferbloat.net/issues/205
>
> I'd implemented a hack to try to address these circular depenencies last
> week in the named-latest package repo, while also coping with
>
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2464
>
> I think I addressed the latter issue, but *good*. :) The 'fix' for the
> ntp/dnssec/bind/network dependencies seems to have some problems, however,
> notably really slow startup in general.
>
>
> To step further back on this:
>
> I had implemented ntp (with 7 contacted servers in the conf file!) in the

IMO 7 is not an extreme number of NTP servers to associate with.  I
help operate a pool NTP server which has 15 associations configured
using maxpoll 8 (256s).  A handful of those are for monitoring
purposes, but the majority are there to provide a wide variety of
stable oscillators, in hopes of keeping better time by giving NTP the
information it needs to ignore transient outliers.  That still amounts
to an average of about 4 queries to lower-stratum "upstream" sources
per minute, which is trivial compared to the 20,000 client NTP queries
it serves each minute (currently averaging 363 pkts/sec).

> first place due to the "cosmic background bufferbloat detector" idea
> extensively discussed on the comp.protocols.ntp newsgroup, and because I
> wanted to be able to compare large sample data sets against known-to-be
> accurate time, with a large deployment of client routers that had a
> configuration I could trust to be accurate, talking to a yet-to-be-deployed
> string of ntp servers (via hopefully a helpful operator) that could work on
> this with us.

Even better would be comparing against a local NTP server set up with
a GPS + PPS (pulse-per-second).  Using off-the-shelf components, the
hardware cost in the US is between $30 and $100.   $30 gets you a Sure
GPS that has PPS but requires good eyes and a steady soldering hand to
bring it from the PCB to the RS-232 connection.  For less than $70 you
can get a Garmin GPS 18x LVC, which requires less accurate soldering
to provide 5VDC power (often via USB) and a DB-9 connector for its
bare-lead 232 connection.  For $100 you can get a ready-to-use 18x LVC
with DB-9 serial and USB power cables provided by a third party.

Cheers,
Dave Hart