https://bugzilla.novell.com/show_bug.cgi?id=699400
https://bugzilla.novell.com/show_bug.cgi?id=699400#c20
--- Comment #20 from Robert Davies 2011-07-13 15:53:23 UTC ---
Because in the bug description, Stefan correctly points out that ntpd, is not
setting the clock to the actual time, which is what the end user expects.
Werner saying (also IMO correctly), that NTP daemon behaviour should not be
changed.
sntps -s sets system time and for hour off, the RTC/CMOS clock appears to get
set right. The issues I had, were IMO Windows bugs, where NTP synchronisation
is set, yet they adjust the clock, causing issue on reboot to Linux.
Setting clock wildly out, it shows it corrected for by -12925 seconds, now I
have :
fir:~ # date
Wed Jul 13 16:43:43 BST 2011
fir:~ # hwclock
Wed Jul 13 20:13:48 2011 -0.234731 seconds
fir:~ # echo peers |ntpdc
peers
remote local st poll reach delay offset disp
=======================================================================
=glfd-dmzutil-1. 82.26.243.130 2 64 177 0.01375 -0.000040 0.07019
=LOCAL(0) 127.0.0.1 10 64 160 0.00000 0.000000 1.39331
=winn-dmzutil-1. 82.26.243.130 2 64 177 0.01601 0.000648 0.06609
=dns1.rmplc.co.u 82.26.243.130 2 64 177 0.01511 -0.001409 0.06371
=utserv.mcc.ac.u 82.26.243.130 2 64 177 0.01910 0.003854 0.07028
*d.st1.ntp.br 82.26.243.130 1 64 177 0.24388 0.016828 0.05862
In /etc/init.d/ntp BEFORE ntpd is started, after system time is set by sntp -s,
one can hwclock -w --noadjfile to make the CMOS clock, roughly correct.
That then lets NTP & kernel 11 minute mode correct for systematic drift as
designed.
As we know & Windows can also these days synchronise to NTP time correctly,
then the solution to this bug, is simple. Set system time, write to hwclock,
when booting up NTP.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.