Dotaz: Přišly CPU Intel o možnost nastavovat čas v minulosti?

[Luboš Doležel (Doli)]

Řeším podivný problém. Mému serveru s Gentoo (Linux 4.10.13) se předbíhá čas. Dělá to asi 6 sekund za 120 dnů, takže nejde o nic super vážného. Jde ale o to, že ntpd není schopné čas udržet synchronizovaný. Po vypnutí ntpd nefunguje ani ruční synchronizace, i když zdánlivě uspěje:

zeus ~ # ntpdate tik.cesnet.cz
29 Aug 20:04:30 ntpdate[683]: step time server 195.113.144.201 offset -6.648793 sec
zeus ~ # ntpdate tik.cesnet.cz
29 Aug 20:04:38 ntpdate[2367]: step time server 195.113.144.201 offset -6.646034 sec
zeus ~ # ntpdate tik.cesnet.cz
29 Aug 20:04:49 ntpdate[4475]: step time server 195.113.144.201 offset -6.636047 sec

Pokud se (při vypnutém ntpd) pokusím ručně změnit čas na něco v minulosti, příkaz uspěje, ale změna se neprojeví:

zeus ~ # date -s "2017-08-29 19:00:00"
Út srp 29 19:00:00 CEST 2017
zeus ~ # date
Út srp 29 20:09:42 CEST 2017

I ve výpisu strace je vidět úspěšné systémové volání. Ze zoufalství jsem zkusil změnit čas na něco v budoucnosti a pak už to nešlo vrátit zpátky. Musel jsem restartovat server (a zabránit uložení do HW hodin).

Nejdřív jsem to bral jako divnou odchylku na serveru, ale pak jsem zjistil, že nemožnost vrátit čas zpět se projevuje i na mém notebooku (s Debianem). To tedy znamená, že i příklad na Debian Wiki je naprosto nefunkční. Nešlo to ani s jádrem ve Stable, ani v Testingu.

Mám tu ještě jeden, starší systém s Gentoo a Linuxem 4.7.4. Tam změna data/času do minulosti funguje. Hodil jsem tam Linux 4.12.7 a stále to funguje. Pak jsem zkusil jeden starší laptop s Debianem Stable a změna data rovněž funguje.

Takže když to shrnu, tak to nevypadá na bug v Linuxu, ale na problém s konkrétními modely CPU. Konkrétně na těchto CPU mi prostě nejde nastavit čas do minulosti:

• Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz
• Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz

Sním či bdím? WTF? Děje se vám to taky?

---

---

Odpovědi

[Vlado]

Nemôže byť súvislosť so systemd?

[Luboš Doležel (Doli)]

To na tom Gentoo neběží.

[majales]

timedatectl?

[lertimir]

Při bežícím ntpd, co dávají dotazy do ntp jádra. Příkazy ntpq a ntpdc. (ten ntpdc na novějších jádrech se už se serverem nespojuje (hlavně díky CVE-2013-5211) a ntpq to přebírá, ale na starší jádrech se s tím dalo dělat více.) Zajímavé jsou přikazy ntpq kerninfo, sysinfo, sysstats. Mě se něco podobného přihodilo před lety, ale byla nějaká virutalizační situace s XENem. ntpdaemon nedokázal předat info hodinám, konstanty pll offset a pll frequency byly na nule v kerninfo

[Luboš Doležel (Doli)]

kerninfo:

ntpq> kerninfo
associd=0 status=c613 leap_alarm, sync_ntp, 1 event, spike_detect,
pll offset:            0
pll frequency:         -6.86299
maximum error:         16
estimated error:       16
kernel status:         pll unsync nano
pll time constant:     6
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

sysinfo:

ntpq> sysinfo
associd=0 status=c018 leap_alarm, sync_unspec, 1 event, no_sys_peer,
system peer:        0.0.0.0:0
system peer mode:   unspec
leap indicator:     11
stratum:            16
log2 precision:     -23
root delay:         0.000
root dispersion:    1.425
reference ID:       STEP
reference time:     00000000.00000000  Thu, Feb  7 2036  7:28:16.000
system jitter:      0.000119
clock jitter:       0.000
clock wander:       0.000
broadcast delay:    -50.000
symm. auth. delay:  0.000

sysstats:

ntpq> sysstats
uptime:                 32032
sysstats reset:         32032
packets received:       3709
current version:        3582
older version:          106
bad length or format:   0
authentication failed:  0
declined:               0
restricted:             0
rate limited:           0
KoD responses:          0
processed for time:     2568

[lertimir]

Ty nejsi k nikomu přivázaný. položka system peer: a položka reference ID: STEP znamená že si jedeš hodiny za své. Co máš v /etc/ntp.conf? jaké tam jsou servery? Co dostaneš příkazem ntpq -c pe a ntpq -c as?

normální sysinfo je

ntpq -c sysi
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
system peer:        netopyr.hanacke.net:123
system peer mode:   client
leap indicator:     00
stratum:            2
log2 precision:     -23
root delay:         12.184
root dispersion:    8.292
reference ID:       94.124.107.190
reference time:     dd512051.ee64b64e  Wed, Aug 30 2017 13:30:25.931
system jitter:      4.910560
clock jitter:       6.812
clock wander:       0.072
broadcast delay:    -50.000
symm. auth. delay:  0.000

tedy definovaný peer (server odkud bereš čas), stratum 16 znamená že jsi bez spojení. Zkontroluj firewall.

[Luboš Doležel (Doli)]

Vyresetoval jsem frekvenci přes adjtimex na nulu, výsledek je tento:

zeus ~ # ntpq -c pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*tik.cesnet.cz   195.113.144.238  2 u    1   64   17   18.820  -5255.7   1.758
+ntp1.tdc.fi     .GPS.            1 u    5   64   17   60.445  -5255.4   0.927
+time.shf.uk.as4 193.150.34.2     3 u    2   64   17   57.138  -5254.2   0.848
-test.diarizer.c 218.73.139.35    2 u    2   64   17  188.613  -5262.8   1.374
-ntp.katho.be    193.190.230.66   2 u    7   64   17   47.147  -5251.6   1.036
zeus ~ # ntpq -c as

ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 11218  961a   yes   yes  none  sys.peer    sys_peer  1
  2 11219  941a   yes   yes  none candidate    sys_peer  1
  3 11220  9424   yes   yes  none candidate   reachable  2
  4 11221  9354   yes   yes  none   outlier   reachable  5
  5 11222  93b4   yes   yes  none   outlier   reachable 11

zeus ~ # ntpq -c kerni
associd=0 status=c613 leap_alarm, sync_ntp, 1 event, spike_detect,
pll offset:            0
pll frequency:         -6.86299
maximum error:         16
estimated error:       16
kernel status:         pll unsync nano
pll time constant:     6
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

zeus ~ # ntpq -c sysi
associd=0 status=c613 leap_alarm, sync_ntp, 1 event, spike_detect,
system peer:        tik.cesnet.cz:123
system peer mode:   client
leap indicator:     11
stratum:            3
log2 precision:     -20
root delay:         19.598
root dispersion:    6202.090
reference ID:       195.113.144.201
reference time:     dd51238c.4b60ead8  Wed, Aug 30 2017 13:44:12.294
system jitter:      1.522854
clock jitter:       0.001
clock wander:       0.000
broadcast delay:    -50.000
symm. auth. delay:  0.000

Takže peer už mám, ale čas je nadále nesynchronizovaný. V ntp.conf je toto:

server tik.cesnet.cz prefer
server 0.gentoo.pool.ntp.org
server 1.gentoo.pool.ntp.org
server 2.gentoo.pool.ntp.org
server 3.gentoo.pool.ntp.org

driftfile       /var/lib/ntp/ntp.drift

restrict default kod nomodify notrap nopeer
restrict -6 default kod nomodify notrap nopeer
restrict 127.0.0.1

restrict 10.10.10.0 mask 255.255.255.0 nomodify nopeer notrap

[majales]

Jestli se nepletu tak při rozdílu větším jak 2 sekundy se ntpd už nedokáže sesynchronizovat.. Takže bych teď volil zastavení ntp daemona poak bych použil ntpdate a nakonec bych ntp službu zase spustil..

[Luboš Doležel (Doli)]

Jenže jak píšu hned v úvodním dotazu, čas prostě nelze vrátit zpět. Nefunguje to. Můžu spouštět ntpdate nebo date -s kolikrát chci a čas se nezmění.

Dokonce jsem si napsal vlastní program, co zavolá settimeofday() a hned poté gettimeofday() a ten čas předaný do settimeofday() se prostě nenastaví, pokud je menší než aktuální čas.

[lertimir]

Možná cesta jak to alespon trochu srovant by bylo docpat do položky pll ofset nějaké větší záporné číslo. tím by ntpd více zpomaloval hodiny a bylo by to více adekvátní.

[lertimir]

Ted je problém, že adjustace času se nepředává do jádra. normálně zase by kerninfo by mělo dopadnout nějak takto.

ntpq -c kerni                   
associd=0 status=0618 leap_none, sync_ntp, 1 event, no_sys_peer,
pll offset:            -46.5091
pll frequency:         -31.1978
maximum error:         0.53388
estimated error:       0.016335
kernel status:         pll nano mode=fll
pll time constant:     10
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

pll offset znamená o kolik milisekud (46) si ntpd, myslí že čas je blbe. A pll frequency znamená o kolik mění mnitřní hodiny, aby se dostal do souhlasu s časem z peeru v jednotká ppm part per milion, takže u mne zhruba zpomalí hodiny o 31 mikrosekundy každou sekundu. (a než dopisuji mail tak offset se mi blíží nule a je na -39) a tobě si myslí ntpd že je čas správně, ofset nula a tak žádné modifikace nedělá. Nejaký debug režim ntpd serveru.

[Luboš Doležel (Doli)]

Teď jsem ručně spustil strace ntpd -qgddd a zde je vidět, že čas je alespoň na chvíli přenastaven:

clock_gettime(CLOCK_REALTIME, {tv_sec=1504096155, tv_nsec=632066676}) = 0
clock_settime(CLOCK_REALTIME, {tv_sec=1504096150, tv_nsec=569906000}) = 0
...
write(1, "ntpd: time set -5.062161s\n", 26ntpd: time set -5.062161s
) = 26
clock_gettime(CLOCK_REALTIME, {tv_sec=1504096150, tv_nsec=570400825}) = 0

Jenže když to spustím znovu, tak je čas stále o 5 sekund mimo.

To skoro vypadá, jako by mi v systému běžel ještě nějaký další hajzldémon, co si s časem dělá, co chce, a vrací zpět všechny pohyby času do minulosti.

[lertimir]

Tak ted už mne napadají jen pitomé nápady, ale nezměnilo něco přistupová práva na potřebné položky někde ve stromu /proc nebo /sys a čistě formálně tam zapsat nejde?

[pc2005]

No nejlepší by bylo zjistit kdo (pokud) volá z userspace nebo kernel space tu změnu zpátky.

[lertimir]

jen pro doplnění. Mám Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz. Tím intelem to nebude.

[pc2005]

Ale BIOSem by to už mohlo být, SMI dokáže sledovat přístupy na sběrnici v pohodě.

[Luboš Doležel (Doli)]

i5 tu mám taky a ten mi to nedělá. Teď začnu asi zkoumat, co v systému volá settimeofday/clock_settime. Jsem docela zvědav, na co přijdu.

[pc2005]

Jaký RTC kernel driver se používá na stroji co nefunguje a jakej na stroji co funguje?

[Luboš Doležel (Doli)]

Na obou vidím rtc_cmos, v /proc/driver/rtc jsou prakticky stejné údaje.

[Luboš Doležel (Doli)]

Ještě doplním, že v /sys/devices/system/clocksource/clocksource0/current_clocksource mám tsc, ale změna třeba na acpi_pm k ničemu nevedla.

[pc2005]

tsc? To je ještě někde z doby pentia ne? Já tam mám hpet (High Precision Event Timer). BTW jestli je možný žádat bios o změnu času, tak to klidně může kontrolovat a vracet při změně sám.

[lertimir]

Ted jsem se podival, co mám. a také tsc. Distribuce jednou Centos a 2x Arch, jednou na AMD jednou na intelu. Takže asi je to default.

[pc2005]

Hmm to by mohlo být, já mám vlastní kompilovaný jádro :-/.

[trubicoid2]

tsc je vzdy vybrano pred hpet, protoze je presnejsi a stoji min

ze seznamu /sys/devices/system/clocksource/clocksource0/available_clocksource se vybere ten prvni, pokud neni nestabilni nebo neco

[pc2005]

Jo aha oni ten TSC pak ještě upravili, aby šel znova použít. Si pamatuju že se TSC právě nedoporučovalo protože je závislý na tom zda nějaký jádro stojí nebo je podtaktovaný. Zrovna můj CPU je jeden z těch, kde už je HPET, ale stále je tam ta stará verze TSC :-/.

Ale na udržování RTC by IMO stačily oba .

[R]

Linuxovy cas nijako nesuvisi s CPU, je to ciste SW zalezitost.

[drunkezz]

Samozrejeme toto je nezmysel

NTP silno zavisi na CPU, krasne sa to prejavuje vo vmware kde aj ked hypervisory su rovnake, jednotlive CPu maju mierne rozlisnu frekvenciu a po premigrovani chvilu ntpcku trva kym si "zykne" na novy CPU

odporucam precitat http://support.ntp.org/bin/view/Support/KnownHardwareIssues

D>

[vaše jméno]

Ale takto to v otazce mineno neni, ze.

[dustin]

Přesně tak.

Já bych to restartoval a vlezl bych do setupu. Tam se vždycky dal čas nastavovat. Když tam půjde nastavit, tak to není v hardwaru (v CPU), ale někde v softwaru.

Pak bych si nainstaloval úplně nově svoji oblíbenou linuxovou distribuci a zkoušel bych to na ní.

[Trubicoid2]

A jakej je čas v tom rtc? Nesynchronizuje se to hloupě pořád na rtc náhodou?

[trubicoid2]

a ve svym kernelu mas CONFIG_RTC_SYSTOHC? vice omacky

[Luboš Doležel (Doli)]

Upgradoval jsem na Linux 4.12.12 a už to funguje dobře. Zkrátka v Linuxu 4.10.x musel být nějaký bug, ke kterému se ani na LKML nikdo nepřihlásil, když jsem tam napsal.

Takže jsem měl pravdu, že je to softwarová záležitost, že? http://www.abclinuxu.cz/poradna/linux/show/428619#25

[Luboš Doležel (Doli)]

Softwarový bug to byl, ale hodiny obecně SW věc na Intel CPU nejsou.

Jestliže se hodiny dají ze setupu řídit dopředu i dozadu a z operačního systému to nejde, tak vyzkouším jiný systém, jestli náhodou v tom původním není chyba.

[Luboš Doležel (Doli)]

To je pěkný nápad, ale těžko to budu realizovat na serveru, který nemohu mít mimo provoz.

Ale na notebooku by to patrně šlo.

[k3dAR]

patrne by to slo i na kulickovem pocitadle, ale jak to souvisi s dotazem? ;)