[ntp:hackers] clustered polling times

Dave Hart davehart at gmail.com
Sun Feb 1 18:06:38 UTC 2009


On Sun, Feb 1, 2009 at 2:51 AM, Tim Shoppa <shoppa at trailing-edge.com> wrote:

> Dave Hart <davehart at gmail.com> wrote:
> > ntpd has a tendency to have peer poll times clustered together, which is
> > particularly noticable with maxpoll 12, as seen in this extract of the
> > central columns of ntpq -c peers output:
> >
> >  st t when poll
> > ================
> >   2 u 1353 2048
> >   2 u 1375 2048
> >   2 u  964 2048
> >   2 u 1312 2048
> >   2 u 1278 2048
> >   2 u 1259 2048
> >   2 u 1317 2048
> >   2 u  957 2048
> >   2 u 1331 2048
> >
> > One cluster around 960 seconds ago, the other around 1300.
>
> I've noticed this too, but I always thought it was the case that
> the ntpd algorithms do not optimally deal with large numbers of peers.
> Maybe the flaws you and I see are like you or me pointing out how
> someone who eats 20 times a day doesn't always eat a balanced meal
> every single time. If you set maxpoll to 12, isn't it true that
> by definition you must be satisfied with getting a good time
> once every 2048 seconds?


I'm testing maxpoll 12 trying to be a good network citizen.  I'm not sure
I'd be satisfied with maxpoll 6 against nine different stratum 1 servers :)
But seriously, if I configure a solitary upstream server with maxpoll 12, I
am apparently satisfied sampling that server's time once every 2048
seconds.  But if I configure four of them?  I'm not sure that implies I'm
satisfied with one cluster of samples every 2048 seconds.


> The peer selection algorithms work really really well for throwing
> out falsetickers when there are a small number of peers. Once you
> have e.g. 9 peers the peer selection algorithm can afford to throw
> out multiple good ones and still have plenty left over. So using
> ntpd as a check on multiple servers and paying attention to the
> falseticker column can be very misleading.


It works pretty well throwing out falsetickers when there are a moderate
number of peers, too.  In fact, I would assert the design works better with
more, not less.  I do realize only up to 9 are considered.  I'm not sure
where the idea that NTP is optimized for a small number of peers comes from,
but it's not something I subscribe to.

Cheers,
Dave Hart


More information about the hackers mailing list