On 2017-03-08 11:55, Per Jessen wrote:
Carlos E. R. wrote:
On 2017-03-07 22:28, Per Jessen wrote:
Carlos E. R. wrote:
In my experience it does a very good job. I have 2-3 laptops (12.3 and leap422) - they spend hours suspended or hibernation or just powered off. I've never noticed any problems.
No, you would have to compare the local time with an accurate clock.
Believe me, I do. Don't be silly, Carlos - of course I would notice if the time was suddenly out by a minute or so.
Honestly, if you don't believe it'll work, don't do it. If you want advice - well, it works fine for me, just do it.
Please, don't be mad at me :-)
I tried years ago and it did not work for me. Maybe now it would work.
Sorry, I was a little frustrated last night, long day and such.
Ok! :)
Basically, I'm using ntpd on laptops for over 10 years. Sometimes they have a connection, sometimes they don't. Sometimes they're off/suspended/hibernated for days etc. I don't exactly watch over the clock to see that it is sync'ed, but if there was a problem I feel certain I would have noticed by now.
This is a list of some 1500 restarts since July 2011 (from /var/log/ntp) on my main laptop:
Restarts? Is that reboots? Or just ntpd restart? I enabled ntpd yesterday, and this morning (restore from hibernation at 11:46:25) I noticed the clock was about half a second off. Now I have checked the log:
8 Mar 03:42:52 ntpd[3626]: 193.145.15.15 local addr 192.168.1.129 -> <null> 8 Mar 03:42:52 ntpd[3626]: Deleting interface #5 wlan0, fe80::eee:e6ff:fed7:bb5f%3#123, interface stats: received=0, sent=0, dropped=0, active_time=4743 secs 8 Mar 11:46:51 ntpd[3626]: bind(19) AF_INET6 fe80::eee:e6ff:fed7:bb5f%3#123 flags 0x11 failed: Cannot assign requested address 8 Mar 11:46:52 ntpd[3626]: unable to create socket on wlan0 (6) for fe80::eee:e6ff:fed7:bb5f%3#123 8 Mar 11:46:52 ntpd[3626]: failed to init interface for address fe80::eee:e6ff:fed7:bb5f%3 8 Mar 11:46:54 ntpd[3626]: Listen normally on 7 wlan0 [fe80::eee:e6ff:fed7:bb5f%3]:123 8 Mar 11:46:54 ntpd[3626]: new interface(s) found: waking up resolver 8 Mar 11:47:00 ntpd[3626]: Listen normally on 8 wlan0 192.168.1.129:123 8 Mar 11:47:13 ntpd[3626]: new interface(s) found: waking up resolver 8 Mar 11:47:13 ntpd[3626]: 0.0.0.0 0618 08 no_sys_peer 8 Mar 11:51:32 ntpd[3626]: 0.0.0.0 0613 03 spike_detect +0.399626 s 8 Mar 11:53:41 ntpd[3626]: 0.0.0.0 061c 0c clock_step +0.400094 s 8 Mar 11:53:42 ntpd[3626]: 0.0.0.0 0615 05 clock_sync 8 Mar 11:53:43 ntpd[3626]: 0.0.0.0 c618 08 no_sys_peer
So ntpd somehow decided to do a clock_step and adjust. This is new to me. It doesn't seem to detect the hibernation, but the reappearance of the network interface. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))