[ntp:questions] Automatic time synchronization of local hw clock.

Mimiko vbvbrj at gmail.com
Tue Apr 15 05:52:33 UTC 2014


On 14.04.2014 22:45, Harlan Stenn wrote:
> I would like to see the log files for that situation.  I suspect a
> different problem.  When -g is given we allow the maximum possible time
> adjustment for the initial time correction.  Only after that has been
> done do we re-enable the "panic limit" that defaults to 1000 seconds.

This is the log:
13 Apr 08:31:57 ntpd[7685]: proto: precision = 0.123 usec
13 Apr 08:31:57 ntpd[7685]: ntp_io: estimated max descriptors: 1024,
initial socket boundary: 16
13 Apr 08:31:57 ntpd[7685]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
13 Apr 08:31:57 ntpd[7685]: Listen and drop on 1 v6wildcard :: UDP 123
13 Apr 08:31:57 ntpd[7685]: Listen normally on 2 lo 127.0.0.1 UDP 123
13 Apr 08:31:57 ntpd[7685]: Listen normally on 3 eth0 10.10.0.58 UDP 123
13 Apr 08:31:57 ntpd[7685]: Listen normally on 4 eth1 192.168.8.174 UDP 123
13 Apr 08:31:57 ntpd[7685]: Listen normally on 5 eth2 10.2.4.4 UDP 123
13 Apr 08:31:57 ntpd[7685]: peers refreshed
13 Apr 08:31:57 ntpd[7685]: Listening on routing socket on fd #30 for
interface updates
13 Apr 08:31:58 ntpd[7685]: 195.22.241.131 8011 81 mobilize assoc 49996
13 Apr 08:31:58 ntpd[7685]: 195.22.241.132 8011 81 mobilize assoc 49997
13 Apr 08:31:58 ntpd[7685]: 195.22.241.133 8011 81 mobilize assoc 49998
13 Apr 08:31:58 ntpd[7685]: 178.17.160.12 8011 81 mobilize assoc 49999
13 Apr 08:31:58 ntpd[7685]: LOCAL(1) 8011 81 mobilize assoc 50000
13 Apr 08:31:58 ntpd[7685]: 0.0.0.0 c016 06 restart
13 Apr 08:31:58 ntpd[7685]: 0.0.0.0 c012 02 freq_set kernel -41.584 PPM
13 Apr 08:31:58 ntpd[7685]: 195.22.241.131 8024 84 reachable
13 Apr 08:31:59 ntpd[7685]: 195.22.241.132 8024 84 reachable
13 Apr 08:32:00 ntpd[7685]: 195.22.241.133 8024 84 reachable
13 Apr 08:32:01 ntpd[7685]: 178.17.160.12 8024 84 reachable
13 Apr 08:32:02 ntpd[7685]: LOCAL(1) 8024 84 reachable
13 Apr 08:32:02 ntpd[7685]: LOCAL(1) 903a 8a sys_peer
13 Apr 08:32:02 ntpd[7685]: 0.0.0.0 c515 05 clock_sync
13 Apr 08:37:27 ntpd[7685]: 195.22.241.133 903a 8a sys_peer
13 Apr 08:37:27 ntpd[7685]: 0.0.0.0 0617 07 panic_stop +3601 s; set
clock manually within 1000 s.

As you can see, even if option -g is present on start, a skew of 3601s
(which is 1 hour and a second) got ntpd into panic. This difference came
that the server was last restarted before daylight saving. After
daylight saving server was suddenly unpowered, so shutdown scripts
couldn't correct the hw clock (there is such script).

I don't understand, why so much trouble about clocks in linux? In
windows systems, there is a default time service which synchronise with
some time server or domain controller and automatically sets hw (and
maybe system's internal) clock. If system is set to some localtime,
windows corrects hw clock to localtime also. Here comes problems in dual
boot.

Of course, time servers must have UTC time, but why not correct hw clock
using localtime if it is configured in system? Anyway, the problem is
not about localtime or utc standard, but that ntpd does not correct hw
clock at all. Its related to fact that ntpd can be chroted. But why
there is no mention in docs of ntpd that it will correct only kernel time.

So using that cron job, I hope hw clock will be in sync an no problem
will arise in future.

Thank you.
-- 
Mimiko desu.



More information about the questions mailing list