ntpq - distance exceeds maximum

[karza71]

Hi,

Tried to browse through this forum but didn't find a clear explanation.

ntpq manual page says that the hash sign in front of time source means:

"selected for synchronization but distance exceeds maximum;"

The time source is behind several routers and there's some delay. But what does it mean in this case. Can I still consider that the syncronisation is reliable? The stratum is 2 and the dispersion is quite small.



# ntpq -p
remote refid st t when poll reach delay offset disp
==========================================================
#10.10.50.1 10.10.60.1 2 u 66 512 377 2.15 2.60 7.13
+10.10.50.2 10.10.60.1 2 u 133 512 377 2.15 6.50 4.41

[RAC_1]

offset is also more than 1 and I would not consider it a good time source.

[Devender Khatana · Accepted solution]

Hi,

The expected output should be similar to

ntpq -p
remote refid st t when poll reach delay offset disp
===================================================
*mydb LOCAL(1) 4 u 122 128 377 0.50 -0.020 0.08
+myalt mydb 5 u 13 128 377 0.38 0.077 0.08

I would suggest to have a local ntp server if possible.

HTH,
Devender

[Stuart Abramson]

We always synched one (or two) servers to some fixed time (outside our site) and then synched the rest of our servers to one (or two) servers inside the shop...

Is it important that the time be synched to the US Naval Observatory, or just that all of your servers have the SAME time?

[karza71]

There is quite a number of servers which in turn should syncronize to this server. Previously GPS was used for the syncronization but that solution is not available anymore. Still I would say that it is more important to have exactly same time between the servers.

[rick jones]

From what I've seen, in ntp-speak, "distance" can be either stratum, or hop-count.

http://www.ntp.org/ntpfaq/NTP-s-algo.htm

Is what I've found - of course the _best_place would be to look in the sources, which I suspect are online somewhere.

How many hops does traceroute take to get to that server?

[karza71]

ntpq -p

remote refid st t when poll reach delay offset disp
=========================================================
+10.10.50.1 10.10.60.1 2 u 180 1024 377 2.11 -1.86 5.33
#10.10.50.2 10.10.60.1 2 u 103 1024 377 1.53 -4.72 4.55


The NTP server(10.10.50.1) is the fourth hop and 10.10.60.1 is the sixth hop when running traceroute from this server.

[rick jones]

Had it been more hops than that I'd have guessed it was related to hop count. Alas, at this point, I suspect the best thing is to find ntpq/ntp sources and see the code that puts the hash on the line.

[karza71]

Problem was finally solved after a new NTP server running in Unix was added. Now the syncronization is working normally. Thank you very much for everyone who contributed to solving this case!

[karza71]

closing the thread...

Problem was finally solved after a new NTP server running in Unix was added. Now the syncronization is working normally. Thank you very much for everyone who contributed to solving this case!