[ntp:questions] ntpd: more than 60 s behind
david at ex.djwhome.demon.invalid
Wed Apr 20 07:33:25 UTC 2011
> 188.8.131.52 .ATOM. 1 u 781 1024 377 21.873 56147.1 3375.72
> ptbtime1.ptb.de .PTB. 1 u 747 1024 377 43.859 52929.2 3343.98
> 184.108.40.206 .ATOM. 1 u 764 1024 377 21.023 52838.6 3394.36
> ptbtime2.ptb.de .PTB. 1 u 768 1024 377 43.901 56232.9 3394.40
> nav.metrologie. .ATOM. 1 u 749 1024 377 20.462 52937.8 3346.61
> ptbtime3.ptb.de .PTB. 1 u 785 1024 377 43.870 56161.2 3384.54
> ntp.nsm.pl 220.127.116.11 2 u 759 1024 377 47.775 52883.6 3359.28
Your offsets are all over the place. It looks like your motherboard
clock is beyond salvation, or you are trying to run ntpd on a virtual
machine (whether this is a very silly thing or the best way of achieving
some discipline on one is very controversial at the moment).
In the VM case, please read the archives (e.g. groups.google.com).
Ultimately, I think that ntpq rv will show that they are all being
rejected because the jitter exceeds the maximum allowed error band.
> # your local system clock, should be used as a backup
This is bad advice. It may be used, but only in certain unusual cases.
You should remove all references unless and until all three of the
following are true:
1) you have solved the immediate problem;
2) you are serving time from the machine;
3) you have identified a specific problem that will benefit from its use.
The local system clock is not actually used as a backup, as it is always
used as the time on the system. What this does is to pretend that the
machine is synchronised, for the benefit of downstream systems, when it
One final point. Please do not use stratum 1 servers for a Windows based
time server, and certainly never for a Windows based client. Also don't
do so for any VM based server. The time keeping quality of such
machines doesn't justify putting a load onto those servers.
More information about the questions