[ntp:questions] NTP rootdelay and rootdispersion problem

unruh unruh at invalid.ca
Thu Nov 10 19:43:53 UTC 2011


On 2011-11-10, David Lord <snews at lordynet.org> wrote:
> unruh wrote:
>> On 2011-11-10, balaji u <ubalaji83 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



More information about the questions mailing list