If you manage ntpd clients in a broadcast or multicast configuration, I'm particularly interested in your opinion regarding ntpq's peers and lpeers commands.
peers, often invoked with "ntpq -p", omits associations which are neither configured nor reachable. In this context, configured means the association resulted directly from a ntp.conf directive such as "server tock", as opposed to ephemeral and preemptible associations spun up after initial startup by automatic server discovery schemes (broad/multicast, manycast, pool). lpeers, in contrast, includes all associations. In my use of manycastclient and it's evil twin, the 4.2.7 overhaul of pool, I have found the omission unhelpful, and tended to switch to using "ntpq -c lpeers" (or shorter, "ntpq -clpe") so I can see recently-added preemptible associations during the first poll interval, before they become reachable. This made me curious about when the peers omission is helpful. Dr. Mills mentioned to me that the omission might be appealing to those with ntpd clients in broadcast or multicast configuration. I have relatively little experience with NTP broadcast and multicast nets, particularly with lots of casters. If you have such a configuration, please compare peers vs. lpeers against a broadcast/multicast client. How would you feel if peers were changed to always show all associations as lpeers does? Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
