[ntp:questions] NTP rootdelay and rootdispersion problem

blji ubalaji83 at gmail.com
Fri Nov 18 11:28:25 UTC 2011

On Nov 11, 12:43 am, unruh <un... at invalid.ca> wrote:
> On 2011-11-10, David Lord <sn... at lordynet.org> wrote:
> > unruh wrote:
> >> On 2011-11-10, balaji u <ubalaj... at gmail.com> wrote:
> >>> my device is connected with a NTP server(stratum 5), which shows round-
> >>> trip delay with its primary reference (stratum 3 server) as 550 to 720
> >>> msec and dispersion as 70 to 160.
> >> That is pretty huge. How is it connecting? pony express? Why are you
> >> using such a bad server? (720ms is enough time for the signal to circle
> >> the earth 5 times. Or I guess if it uses a sattelite as part of the link
> >> it could generate delays like that)
> >>> Whether this could be a problem for my NTP client?. The question
> >> Since ntpd jumps if the time gets out by 128 ms, your delay is getting
> >> to the point where successive timings could have offsets of that order..
> >> And ntpd doing jumps a fair amount of the time is not a good idea.
> >>> arises because my NTP server is sending packets with its Root delay
> >>> and Root Dispersion values which could create some problem on the NTP
> >>> client side.
> >> Why are you using such a bad server for your server? Buy a gps receiver
> >> and get usec accuracy for your server and then you can stop worrying.
> >> Or find some better servers to serve your server.
> > I use mobile broadband and have seen latencies of several seconds
> > when the link has been idle. When the link is loaded the lowest
> > latencies have been about 150ms. That's why I joined the pool so
> > that I could use burst against my own server without worrying.
> > Ntp seems to get my netbook within a few milliseconds.
> > The valleys here have steep sides and tops are about 300m above
> > the road. Even mobile broadband isn't always accessible.
> As I said, I would worry about hopping-- ie ntpd thinking you are out by
> 128ms, stepping the clock, only to step back again a few polls later.
> (eg, for a while your route is "highly" assymetric, leading ntpd to
> think it really is >128ms out, and then for some reason it goes
> assymetric the other way.) Now, there is of course no way you can get a
> good time in those situations, but the stepping of the clock is probably
> more worrysome than the poor time accuracy.
> That is a problem with the highly non-linear stepping algorithm of ntpd.
> > David

Thanks to all.
I just need one more information. Currently my NTP server has only one
primary source configured. As I said earlier there is a huge round
trip delay and dispersion between this NTP server and its primary
Why my NTP server is not rejecting this untrusted primary source. It
is still in sync with this primary source where delay is more (550ms
to 720 ms) (poll interval is 1024s)


More information about the questions mailing list