For a newbie confronting NTP for the first time, the most irksome task to overcome is the selection of one or more servers appropriate to the geography at hand. Over the years, this has become something of a black art and the origin of urban legends. There are four schemes to discover candidate servers: ordinary broadcast mechanisms, public lists maintained at the NTP Web site (http://www.ntp.org), the pool scheme based on DNS, and the manycast scheme based on an expanding ring search. These schemes are described in detail in Section 5.8.
There are two public server lists, one for stratum 1 primary servers and the other for stratum 2 secondary servers. The servers on these lists are operated for the Internet at large and come with certain rules of engagement, as indicated in each entry. They are scattered all over the world, with some in exotic places, some behind very long wires, and, soon, some on the Moon. Prominent among them are many operated by government agencies like the NIST and U.S. Naval Observatory (USNO) disseminating UTC from national standards. Potential users are cautioned to avoid the primary servers unless they support sizable NTP subnets of their own. A newbie is advised to scan the secondary server list for two or three nearby candidates and follow the access rules and notification directions.
An automatic discovery scheme called pool has been implemented and is now in regular use. A client includes a number of servers in the configuration file, all specifying the same server http://www.pool.ntp.org or associated country-specific subdomains like us.pool.ntp.org. The DNS server responds with a list of five NTP servers for that country randomly selected from a large pool of participating volunteer servers. The client mobilizes associations for each configured server. Subsequently, statistical outliers are systematically pruned and demobilized until the best three remain.
Manycast is an automatic discovery and configuration paradigm new to NTPv4. It is intended as a means for a client to troll the nearby network neighborhood using broadcast mode and an expanding-ring search. The object is to (1) find cooperating servers, (2) validate them using cryptographic means, and (3) evaluate their time values with respect to other servers that might be lurking in the vicinity. The intended result is that each unicast client mobilizes client associations with the best three of the available servers yet automatically reconfigures to sustain this number of servers should one or another fail.
Note that the manycast paradigm does not coincide with the anycast paradigm described in RFC-1546 [2], which is designed to find a single server from a clique of servers providing the same service. The manycast paradigm uses an expanding-ring search to find a plurality of redundant NTP servers and then prune the population until only the highest-quality survivors are left. There are many details about the protocol operations and configuration that can be found in the user documentation and on the Web.
