[linux] Tijd heeft steeds afwijking, ook met NTP?

[willemd]

Hoi! Ik draai een thuisserver op basis van Debian jessie, amd64. Sinds een tijdje loopt de klok standaard circa 21 seconden voor. Dat blijft telkens hetzelfde, ook na ntpdate te draaien (van meerdere servers).

code:

root@senseo:~# ntpdate time.nist.gov
 2 Mar 09:40:02 ntpdate[6647]: step time server 128.138.141.172 offset -21.933278 sec
root@senseo:~# ntpdate ntp1.euro.net
 2 Mar 09:40:19 ntpdate[6666]: step time server 194.134.65.196 offset -21.924347 sec

Als ik de tijd vergelijk met mijn Windows-laptop loopt de server ook inderdaad die 21 seconden voor.

De klok loopt verder wel in het juiste tempo; de offset blijft ook na dagen rond de 21 seconden. Ik geloof niet dat het echt kwaad kan, maar ik snap er niks van dat ie dit doet. Het was altijd zo dat de offset binnen een seconde bleef.

Iemand enig idee wat dit kan zijn? Of hoe ik erachter kan komen wat er aan de hand is?

[CAPSLOCK2000]

Vreemd, het zou op zich kunnen dat die twee timeservers die je gebruikt zelf niet in pas lopen, al is dat een beetje onwaarschijnlijk. Gebeurt het ook als je twee keer dezelfde server gebruikt?

Geef eens '-d' mee, dan krijg je debug-informatie, misschien heb je daar iets aan.

Normaal gesproken probeert NTP de tijd goed te krijgen door langzaam aan de knoppen te draaien. Er is ook een optie om direct naar de juiste tijd te springen. Zie de manpage, al vind ik 21 seconde eigenlijk helemaal niet veel.

Kan het zijn dat er nog een andere NTP actief is, bv een ntp of chrony-daemon of een cronjobje dat NTPdate aanroept, dat naar een andere server kijkt. Er zijn bijvoorbeeld routers die ook een ntp-daemon aan boord hebben. Dat soort info wordt vaak via DHCP doorgegeven, kijk dus even of er geen gekke NTP-opties in je DCHP-leases zitten.

[deadinspace]

Kijk ook eens of er iets in je logs verschijnt (met name /var/log/messages en /var/log/syslog) op het moment dat je ntpdate aanroept.

[CyBeR]

CAPSLOCK2000 schreef op maandag 02 maart 2015 @ 10:25:
Normaal gesproken probeert NTP de tijd goed te krijgen door langzaam aan de knoppen te draaien. Er is ook een optie om direct naar de juiste tijd te springen.

Dat geldt voor ntpd. TS gebruikt in zijn voorbeeld ntpdate en die zet wel gewoon in één keer de klok goed. Normaal gesproken tenminste.

[willemd]

De logs in /var/log/messages en /var/log/syslog zijn op de tijden dat ik ernaar keek leeg helaas.


Het gekke is dat als ik handmatig de tijd aanpas, dat ook niet werkt!

Onderstaande heb ik binnen twee seconden gedaan. Eerst heb ik de tijd op tijd gezet (nav mijn Windows-klok, en dus ca 21 seconden vroeger), en direct daarna 'date' gebruikt om de systeemklok uit te lezen. Hij staat meteen weer 21 seconden later. (Nu ik het kopieer en plak, zie ik dat ik de datum verkeerd getypt had. Dat zou volgens mij niet uit mogen maken? Maar ook die is dus teruggezet.)

code:

root@senseo:~# date -s "2015-03-01 15:24:10"
Sun Mar  1 15:24:10 CET 2015
root@senseo:~# date
Mon Mar  2 15:24:33 CET 2015

Kan het zijn dat een ander proces de tijd blokkeert, of dat de hardware clock niet valt aan te passen? (Als ik hwclock -r doe, krijg ik ook de 'foute' tijd in beeld.)

[Blokker_1999]

Dit is een bare-metal systeem? Er zit geen VM/hypervisor onder?

[willemd]

Nope, gewoon alleen die Linux-installatie!

[deadinspace]

Het Leoh-Paard schreef op maandag 02 maart 2015 @ 15:32:
Kan het zijn dat een ander proces de tijd blokkeert

"Blokkeren" kan niet echt, maar mogelijk draait er een proces dat regelmatig de tijd terugzet naar de foute waarde, vandaar dat CAPSLOCK2000 begon over een ander NTP-programma. Kun je eens de output van

ps auxf

posten?

of dat de hardware clock niet valt aan te passen?

Als ik me niet vergis wordt de hardware clock alleen gelezen bij het opstarten en geschreven bij het afsluiten, dus ik vermoed dat dat niet het probleem is hier (maar dat weet ik niet zeker).

[willemd]

Dat is het volgende:

Het is een mediaserver voor Kodi en Squeezeboxen, en draait dingen als MySQL, Sabnzbdplus, Sickbeard, Tvheadend, Oscam, Squeezeboxserver (logitechmediaserver) en Samba.

Ik weet dat Tvheadend een optie heeft om de tijd uit DVB-signalen te lezen, maar dat heb ik uitstaan.

code:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         2  0.0  0.0      0     0 ?        S    Mar01   0:00 [kthreadd]
root         3  0.0  0.0      0     0 ?        S    Mar01   0:11  \_ [ksoftirqd/0]
root         5  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [kworker/0:0H]
root         7  0.0  0.0      0     0 ?        S    Mar01   0:58  \_ [rcu_sched]
root         8  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [rcu_bh]
root         9  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [migration/0]
root        10  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [watchdog/0]
root        11  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [watchdog/1]
root        12  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [migration/1]
root        13  0.0  0.0      0     0 ?        S    Mar01   0:19  \_ [ksoftirqd/1]
root        15  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [kworker/1:0H]
root        16  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [khelper]
root        17  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [kdevtmpfs]
root        18  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [netns]
root        19  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [khungtaskd]
root        20  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [writeback]
root        21  0.0  0.0      0     0 ?        SN   Mar01   0:00  \_ [ksmd]
root        22  0.0  0.0      0     0 ?        SN   Mar01   0:00  \_ [khugepaged]
root        23  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [crypto]
root        24  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [kintegrityd]
root        25  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [bioset]
root        26  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [kblockd]
root        29  0.0  0.0      0     0 ?        S    Mar01   0:10  \_ [kswapd0]
root        30  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [fsnotify_mark]
root        36  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [kthrotld]
root        37  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [ipv6_addrconf]
root        39  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [deferwq]
root        77  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [khubd]
root        78  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [ata_sff]
root        79  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [scsi_eh_0]
root        80  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [scsi_tmf_0]
root        81  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [scsi_eh_1]
root        82  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [scsi_tmf_1]
root        83  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [scsi_eh_2]
root        84  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [scsi_tmf_2]
root        85  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [scsi_eh_3]
root        86  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [scsi_tmf_3]
root        87  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [scsi_eh_4]
root        88  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [scsi_tmf_4]
root        90  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [scsi_eh_5]
root        91  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [scsi_tmf_5]
root        94  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [scsi_eh_6]
root        95  0.0  0.0      0     0 ?        S    Mar01   0:02  \_ [kworker/u12:5]
root        96  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [scsi_tmf_6]
root       101  0.0  0.0      0     0 ?        S<   Mar01   0:05  \_ [kworker/1:1H]
root       104  0.0  0.0      0     0 ?        S<   Mar01   0:10  \_ [kworker/0:1H]
root       110  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [scsi_wq_0]
root       135  0.0  0.0      0     0 ?        S    Mar01   0:17  \_ [jbd2/sdc2-8]
root       136  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [ext4-rsv-conver]
root       374  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [ddbridge]
root       386  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [ttm_swap]
root       411  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [radeon-crtc]
root       415  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [radeon-crtc]
root       516  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [hd-audio0]
root       521  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [edac-poller]
root       546  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [kvm-irqfd-clean]
root      1434  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [jbd2/sdc3-8]
root      1435  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [ext4-rsv-conver]
root      1439  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [jbd2/sde2-8]
root      1440  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [ext4-rsv-conver]
root      1441  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [jbd2/sde4-8]
root      1442  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [ext4-rsv-conver]
root      1443  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [jbd2/sde5-8]
root      1444  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [ext4-rsv-conver]
root      1445  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [jbd2/sdg2-8]
root      1446  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [ext4-rsv-conver]
root      1450  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [jbd2/sdh1-8]
root      1451  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [ext4-rsv-conver]
root      1452  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [jbd2/sdh2-8]
root      1453  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [ext4-rsv-conver]
root      1454  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [jbd2/sda1-8]
root      1455  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [ext4-rsv-conver]
root      1456  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [jbd2/sdm1-8]
root      1457  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [ext4-rsv-conver]
root      1458  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [jbd2/sdl1-8]
root      1459  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [ext4-rsv-conver]
root      1460  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [jbd2/sdj1-8]
root      1461  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [ext4-rsv-conver]
root      1462  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [jbd2/sdg3-8]
root      1463  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [ext4-rsv-conver]
root      1464  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [jbd2/sdn1-8]
root      1465  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [ext4-rsv-conver]
root      1469  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [jbd2/sdd1-8]
root      1470  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [ext4-rsv-conver]
root      1477  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [jbd2/sdi1-8]
root      1478  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [ext4-rsv-conver]
root      1485  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [jbd2/sdf1-8]
root      1486  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [ext4-rsv-conver]
root      1490  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [jbd2/sdb1-8]
root      1491  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [ext4-rsv-conver]
root      1495  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [jbd2/sdh3-8]
root      1496  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [ext4-rsv-conver]
root      1500  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [jbd2/sdk1-8]
root      1501  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [ext4-rsv-conver]
root      1511  0.0  0.0      0     0 ?        S    Mar01   0:02  \_ [jbd2/sdg1-8]
root      1512  0.0  0.0      0     0 ?        S<   Mar01   0:00  \_ [ext4-rsv-conver]
root      3531  0.0  0.0      0     0 ?        S    Mar01   0:00  \_ [kauditd]
root      4539  0.0  0.0      0     0 ?        S    Mar01   0:08  \_ [kdvb-ad-1-fe-0]
root      4540  0.0  0.0      0     0 ?        S    Mar01   0:10  \_ [kdvb-ad-0-fe-0]
root     12136  0.0  0.0      0     0 ?        S    04:32   0:02  \_ [kworker/u12:0]
root      5952  0.2  0.0      0     0 ?        S    09:32   1:17  \_ [kworker/1:0]
root     31536  0.0  0.0      0     0 ?        S    16:04   0:01  \_ [kworker/0:0]
root      5598  0.0  0.0      0     0 ?        S    16:49   0:00  \_ [kworker/1:2]
root      5599  0.0  0.0      0     0 ?        S    16:49   0:07  \_ [kworker/0:2]
root         1  0.0  0.0  15484  1584 ?        Ss   Mar01   0:01 init [2]
root       327  0.0  0.0  41444  2052 ?        Ss   Mar01   0:00 udevd --daemon
root      1741  0.0  0.0  37068  1996 ?        Ss   Mar01   0:00 /sbin/rpcbind -w
root      2031  0.0  0.0 258664  2452 ?        Ssl  Mar01   0:01 /usr/sbin/rsyslogd
root      2076  0.0  0.0  23552  2256 ?        S    Mar01   0:00 /sbin/cgmanager --daemon -m name=systemd
root      2108  0.0  0.0   4248  1404 ?        Ss   Mar01   0:00 /usr/sbin/acpid
root      2143  0.0  0.0 196876  5052 ?        Ss   Mar01   0:01 /usr/sbin/nmbd -D
usenetd+  2168  0.3  1.0 1265664 85564 ?       Sl   Mar01   5:56 /usr/bin/python SickBeard.py -q --daemon --nolaunch --pidfile=/var/run/sickbeard/sickbeard.pid --datadir=/home/usenetdownloa
daemon    2209  0.0  0.0  19012   168 ?        Ss   Mar01   0:00 /usr/sbin/atd
root      2262  0.0  0.0  27464  2088 ?        Ss   Mar01   0:00 /usr/sbin/cron
root      2309  0.0  0.0  19268  1852 ?        Ss   Mar01   0:10 /usr/sbin/irqbalance --pid=/var/run/irqbalance.pid
message+  2320  0.0  0.0  42236  2500 ?        Ss   Mar01   0:00 /usr/bin/dbus-daemon --system
root      2853  0.0  0.1 276848 13032 ?        Ss   Mar01   0:03 /usr/sbin/smbd -D
root     17291  0.0  0.2 281996 17332 ?        S    10:33   0:17  \_ /usr/sbin/smbd -D
root     21383  0.4  0.1 285808 16264 ?        S    18:40   0:13  \_ /usr/sbin/smbd -D
monehtpc 21641  0.0  0.1 281516 16212 ?        S    18:42   0:00  \_ /usr/sbin/smbd -D
usenetd+  2904  0.4  1.7 1399516 139460 ?      Sl   Mar01   7:24 /usr/bin/python -OO /usr/bin/sabnzbdplus --daemon --pidfile /var/run/sabnzbdplus/pid --server 0.0.0.0:9090
root      3009  0.0  0.0  25388  6884 ?        Ss   Mar01   0:00 dhclient -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0
root      3051  0.0  0.0  55160  2812 ?        Ss   Mar01   0:00 /usr/sbin/sshd
root     27731  0.3  0.0  95332  6264 ?        Ss   19:26   0:00  \_ sshd: root@pts/0
root     27742  0.2  0.0  24352  6076 pts/0    Ss   19:26   0:00      \_ -bash
root     27784  0.0  0.0  19252  2524 pts/0    R+   19:26   0:00          \_ ps auxf
squeeze+  3451  0.0  0.0  11628  1656 ?        S    Mar01   0:00 /bin/bash /usr/sbin/squeezeboxserver_safe /usr/sbin/squeezeboxserver --prefsdir /var/lib/squeezeboxserver/prefs --logdir /va
squeeze+  3458  0.1  1.5 233396 127864 ?       S    Mar01   1:41  \_ /usr/bin/perl /usr/sbin/squeezeboxserver --prefsdir /var/lib/squeezeboxserver/prefs --logdir /var/log/squeezeboxserver/
squeeze+  3490  0.1  0.0 221532  6740 ?        Sl   Mar01   2:08      \_ /var/lib/squeezeboxserver/cache/InstalledPlugins/Plugins/Spotify/Bin/i386-linux/spotifydnoflac64 /var/log/squeezebox
root      3476  0.0  0.0  14408  1876 tty1     Ss+  Mar01   0:00 /sbin/getty 38400 tty1
root      3477  0.0  0.0  14408  1776 tty2     Ss+  Mar01   0:00 /sbin/getty 38400 tty2
root      3478  0.0  0.0  14408  1704 tty3     Ss+  Mar01   0:00 /sbin/getty 38400 tty3
root      3479  0.0  0.0  14408  1880 tty4     Ss+  Mar01   0:00 /sbin/getty 38400 tty4
root      3480  0.0  0.0  14408  1776 tty5     Ss+  Mar01   0:00 /sbin/getty 38400 tty5
root      3481  0.0  0.0  14408  1708 tty6     Ss+  Mar01   0:00 /sbin/getty 38400 tty6
root      3533  0.0  0.0  28260  2592 ?        S    Mar01   0:00 /lib/systemd/systemd-logind
root      3640  0.0  0.0   4328  1464 ?        S    Mar01   0:00 /bin/sh /usr/bin/mysqld_safe
mysql     3968  0.2  1.9 882916 158488 ?       Sl   Mar01   3:18  \_ /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --pid-file=/var
root      3969  0.0  0.0  23708  1752 ?        S    Mar01   0:00  \_ logger -t mysqld -p daemon.error
hts       4504  2.6  4.8 1658072 394220 ?      Ssl  Mar01  40:02 /usr/bin/tvheadend -f -u hts -g video
hts      27634  3.9  0.3 135492 29268 ?        S    19:26   0:02  \_ python /usr/bin/tv_grab_nl
root     10809  0.0  0.0  24716   392 ?        Ss   09:47   0:00 /usr/bin/oscam-svn --daemon --pidfile /var/run/oscam-svn.pid --debug 0 --restart 2 --config-dir /etc/oscam-svn --temp-dir /t
root     10810  0.4  0.0 511556  5592 ?        S<l  09:47   2:29  \_ /usr/bin/oscam-svn --daemon --pidfile /var/run/oscam-svn.pid --debug 0 --restart 2 --config-dir /etc/oscam-svn --temp-di

[Mijzelf]

Je kunt de hardware klok in de bios even een heel andere waarde geven, om te kijken of die wordt uitgelezen.

[begintmeta]

Inderdaad even checken wat het verschil is als je de hwclock zelf anders zet/uitleest.

Ik dacht bij het lezen van de topictitel in eerste instantie aan een gek probleem met schrikkelsecondes of tijdzones, maar het aantal 21 (noch überhaupt het onstaan van hrt probleem) zou ik dan niet direct kunnen verklaren.

[ Voor 7% gewijzigd door begintmeta op 02-03-2015 20:54 ]

[chronoz]

Misschien komt het door de hardware clock die de system time opnieuw instelt inderdaad. hwclock --systohc?

code:

hwclock
ntpdate time.nist.gov
hwclock --systohc
ntpdate time.nist.gov
- reboot -
ntpdate time.nist.gov

[dunklefaser]

Ik zou in eerste instantie de lopende ntpd met ntpq checken
Hoe ziet de ntp.conf überhaupt uit?

ntpq check op een Synology NAS (Internet glasvezel 50/50 via FB7390)

code:

> ntpq
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
=================================================================
*fritz.box       213.136.0.252    2 u  144  256  377    0.407   -0.032   0.055
ntpq> lo
     remote           local      st t when poll reach   delay   offset    disp
=================================================================
*fritz.box       _32ff:fe0f:xxxxx  2 u  154  256  377    0.407   -0.032  10.187
ntpq> q

Resultaat van een query met ntpdate (de fritz.box haalt de tijd wederom van de 0.europe.pool.ntp.org)

> ntpdate -q 0.europe.pool.ntp.org
server 178.18.118.14, stratum 2, offset -0.000689, delay 0.03682
server 5.9.110.236, stratum 2, offset -0.000185, delay 0.03976
server 37.221.192.191, stratum 2, offset -0.000253, delay 0.04010
server 46.38.236.74, stratum 2, offset 0.003213, delay 0.04031
13 Mar 14:45:04 ntpdate[16487]: adjust time server 178.18.118.14 offset -0.000689 sec

kernelparams

ntpq> ker
associd=0 status=0618 leap_none, sync_ntp, 1 event, no_sys_peer,
pll offset:            -0.06541
pll frequency:         -11.3697
maximum error:         0.179998
estimated error:       0.000112
kernel status:         pll nano
pll time constant:     8
precision:             1e-06
frequency tolerance:   500
pps frequency:         0
pps stability:         0
pps jitter:            0
calibration interval   0
calibration cycles:    0
jitter exceeded:       0
stability exceeded:    0
calibration errors:    0

Dus een accuracy van beter dan minimaal enkele millisekonden is makkelijk haalbaar (=afwijking van de officiële (atoom)tijd). (Meer dan 10 msec vind ik trouwens niet meer acceptabel met de huidige Internetverbindingen)
Bij een lopende ntpd trouwens nooit ntpdate gebruiken om de tijd te zetten en anders bij grotere afwijkingen sowieso ntpd met iburst starten.

[willemd]

(Gek genoeg kreeg ik geen melding van t.net dat er weer gereageerd is, vandaar deze late reactie.)


Ik heb er verder naar gekeken. De hardware-clock loopt wel gewoon 'ongeveer' op tijd. (En is ongeveer hetzelfde als op mijn desktop.) Dus de system clock heeft een constante afwijking. Of nou ja, heel constant is de afwijking niet: Inmiddels is de afwijking 99 seconden. Dat loopt blijkbaar met een seconde per dag ofzo op.
Ik zie dat ik in een post eerder schreef dat de hwclock ook afweek - ik snap niet zo goed waarom dat nu anders zou zijn, dus ofwel heb ik me toen vergist (betwijfel dat eigenlijk), ofwel er is iets veranderd.)

code:

root@senseo:~# date
Thu May 28 16:22:09 CEST 2015
root@senseo:~# hwclock
Thu 28 May 2015 04:21:07 PM CEST  .327534 seconds
root@senseo:~# ntpdate ntp1.euro.net
28 May 16:20:46 ntpdate[465]: step time server 194.134.65.196 offset -99.834764 sec
root@senseo:~# date
Thu May 28 16:22:27 CEST 2015
root@senseo:~# hwclock
Thu 28 May 2015 04:21:24 PM CEST  .171166 seconds

Dus 'iets' wijzigt de system clock ten opzichte van de hwclock. Maar wat?


@dunklefaser: Ik draai geen ntpd-service voor zover ik weet. Zo heel af en toe doe ik handmatig ntpdate om een seconde afwijking ofzo te corrigeren - of althans, daar ben ik mee opgehouden nu het geen zin meer heeft.

[chronoz]

Ja goeie vraag. Je kunt een cronjob instellen die elke minuut de software clock corrigeert.

Indien je software-klok wel goed is, maar je hardware-klok niet, kun je de hardware-klok corrigeren met hwclock --systohc.

Hoe lang duurt het trouwens voordat de hardware-klok en software-klok weer uit elkaar liggen?

[willemd]

Er zit tussen bovenstaande commando's hooguit een seconde ofzo. Dus ntpdate corrigeert de system time, en die valt dan direct weer terug op de oude afwijking. (
Of: de system time kan niet worden aangepast, maar ntpdate heeft dat niet in de gaten. Aangezien ik het in de startpost ook handmatig met 'date' heb geprobeerd, denk ik dat niet.)

Dus de hardware clock loopt goed, de system clock heeft - ook bij handmatige correctie - continu een grote afwijking. Ik kan de clock dus blijkbaar niet softwarematig corrigeren - ofwel omdat hij gewoon niet reageert op een correctie, ofwel omdat een ander proces/kernel/magie de tijd direct weer verandert.


Het maakt me op zich niet zoveel uit dat de klok niet precies op tijd loopt, maar ik wil graag begrijpen waarom die afwijking erin zit. (En als het ff kan, het ook oplossen natuurlijk.)

[Blokker_1999]

als je ntpdate kan draaien heb je geen ntpd service draaien. Die 2 kunnen niet gelijktijdig.

Een afwijking van 1s per dag lijkt mij niet abnormaal, heb al systemen gehad die een grotere afwijking hadden. En daar heb je net de ntpd service voor om dat te corrigeren.

ntpdate (de tool waarmee men het handmatig kan doen) is trouwens al weer enkele jaren deprecated: http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate

[Thc_Nbl]

gebruik een "stabiele" stratum 1 server voor je tijd syncronisatie en niet de pools.

zet in je /etc/ntp.conf
server ntp1.nl.net
en zet alle "pool" servers uit.

doe dan even het volgende.

service ntp stop
ntpdate ntp1.nl.net
service ntp start
hwclock --systohc

Je probleem wordt dus veroorzaakt door de "pool" servers, die lopen niet allemaal gelijk,
met als gevolg dat als je van server wisselt, er een tijd verschil is.
daarom dus een stratum 1 server.
zie www.ntp.org

[ Voor 28% gewijzigd door Thc_Nbl op 29-05-2015 11:30 ]

[Blokker_1999]

ipv `ntpdate timeserver` kan je beter `nptd -gq`uitvoeren. Het effect is gelijkaardig alleen maak je dan niet langer gebruik van deprecated software (en de sterk verouderde ntp implementatie). hoewel het niet langer noodzakelijk is om de tijd correct te zetten voor het starten van de ntpd (deze moet slechts binnen de 64 jaar van de huidige datum zitten) is de deamon traag om deze terug in sync te brengen.

Er word ook met een pool gewerkt net omdat geen enkele server de absolute waarheid in pacht heeft. Uit die pool word binnen enkele seconden een relatief correcte tijd bepaald. Zelfs wanneer je ntpd wil gebruiken met andere timeservers dan in de conf staan word aangeraden om meerdere servers te gebruiken voor synchronisatie.

[willemd]

Maar het punt is dat ook met handmatig aanpassen van de system clock, er niets gebeurt. De klok heeft een afwijking die ik niet kan veranderen. Ik snap er niks van.


Ik heb overigens op jullie aanraden ntpd geïnstalleerd, dat gedraaid met ntpd -gq. Het gevolg is dat nu ook de hardware clock 99 a 100 seconden voorloopt. Die heeft hij dus gesynchroniseerd met de system clock. Dus mijn laptop staat op 14:25 (correct), de server op 14:27. Als ik de ntpd-service stop, dan ntpdate draai, geeft hij ook netjes een afwijking van 100.xxx seconden aan. Maar blijkbaar kan het niet gecorrigeerd worden.

[begintmeta]

Kennelijk is de afwijking toch niet constanmt 21s,m aar neemt die toe. Laat ntpd maar een tijdje (weekje bijvoorbeeld) als service draaien (meerdere servers uit te pool instellen zou ok moeten zijn) en kijk wat er gebeurt met de klokverschuiving. Eventueel is het ook interessant eens een paar keer te kijken wat de inhoud van /var/lib/ntp/ntp.drift is. Verder kan je eventueel eens posten vat de clocksource is die in de kernel-messages wordt genoemd.