Skok systémového času Windows

[jardaplc]

Tak potvrzeno, v ESXi byl o těch 46 minut špatný (neudržovaný čas). No a když denní drift  je asi -0,8 vteřiny, server jsme pořizovali zhruba před 2,5 lety, tak to krásně vychází, že se od té doby posunul zhruba o 15 minut dozadu. No a jelikož při pořízení byl letní čas, tak proti aktuálnímu času je to těch 45 minut dopředu.
<Facepalm>
Mohlo mě to napadnout dřív, než jsem tady začal plašit; ale diskuze byla myslím alespoň pro mě docela poučná.

Jako anekdotu na závěr můžu zmínit, že virtuálku jsme používali interně ve firmě na vyčítání události z Jablotroní sběrnice (příchody / odchody lidí dle pípnutí karty). Takže lidi, co měli to štěstí a přišli před tím, než si virtuálka ráno chytla správný čas, měli občas zvědavé dotazy, proč mají v systému příchod v 7:46 kyž si pípli v 7:00 

[Reklama]

[Zdeno Sekerák]

Kromě 26.10., kde vidím skok ve dvě o 3600s při změne času

26.10.2025 se menil letny cas

[František Ryšánek]

Gratuluji k vyřešení, a děkuji za zajímavý dotaz.

Přestože teď máte hypervizor už zasynchronizovaný, doporučuji ponechat guestům aktivní pouze jeden způsob synchronizace: w32time, nebo VMware Tools, nebo nějaký další. Pokud necháte aktivní dva nebo více způsobů synchronizace uvnitř jednotlivého guesta, zvyšuje se riziko "zvláštních efektů" (houpání zpětnovazební smyčky dolaďování frekvence apod.)

Mimochodem, ohledně přechodů zimní/letní čas... UNIX jede interně UTC, Windows podle mého taky. Časová zóna a střídání zimního/letního času je za běhu záležitostí prezentace v uživatelském rozhraní (s podporou systému).
Doporučil bych nastavit vindózům ve VM, ať si čas do emulovaného RTC ukládají v UTC (především bez střídání letního a zimního času). Pak by Vám měly odpadnout skokové změny, pokud guest VM změnu času "prospal" ve vypnutém stavu.

Zdá se, že emulovaný RTC (jak ho vidí guest VM) umí uložit aktuální čas guesta - ovšem neukládá ho jako absolutní čas, ale jako offset oproti času hostitele=hypervizoru. Emulovaný RTC proto při vypnutém guestovi nedriftuje, "tiká pořád přesně". Ofset emulovaného RTC lze snad také nastavit explicitně, per guest...
Ohledně chování emulovaného RTC ve VMware najde Google jenom letité PDFko (kapitola "Virtual CMOS RTC" na str.7). Meinbergové mluví také o VMware knowledge-base záznamu na téma timekeeping - netuším, jestli je to dnes k dispozici jenom po přihlášení / v rámci placeného supportu nebo jak.

[LacconePanda]

K tomu bych měl dotaz, počítá si windows nějak "ticky času" že ví že běžel třeba x dní čistého času (po nějakých třeba minutových checkpointech) a pak se nastřádaný drift času při posunu systémového data v hypervizoru /biosu/nastavení času v guestovi  nějak projeví?

[František Ryšánek]

K tomu bych měl dotaz, počítá si windows nějak "ticky času" že ví že běžel třeba x dní čistého času (po nějakých třeba minutových checkpointech) a pak se nastřádaný drift času při posunu systémového data v hypervizoru /biosu/nastavení času v guestovi  nějak projeví?

Nerozumím otázce :-( Zkuste to pomaleji, pro mě pomalejšího...

Podrobnosti:

Zjistit uptime ve Windows lze, nejsnáz asi v Task Manageru = správci úloh (Ctrl+Shift+Esc), menu vlevo Výkon -> Procesor. V levém dolním rohu je číslo ve formátu dny:hodiny:minuty:sekundy od startu.
Datum a čas posledního startu se dá zjistit z příkazového řádku takto:

systeminfo | find "System Boot Time"

Windowsy při startu natáhnou momentální lidský čas z RTC, a při vypnutí aktuální čas do RTC uloží. RTC je maličký šváb nebo blok v čipsetu někde na motherboardu, zálohovaný knoflíkovou baterkou. Má krystal 32768 Hz, děličku 1/2^15 a pár registrů mapovaných do IO space hostitelského procesoru.

Mezi startem a vypnutím jede čas softwarově. HW RTC kdesi na motherboardu sice za běhu OS běží dál, ale nebere se na něj ohled. OS si jede "v softwaru" svoji vlastní runtime časovou základnu. Tato softwarová časová základna používá jeden z několika HW čítačů/časovačů architektury PC, kterým se nechá pravidelně budit pomocí IRQ. V DOSu tradičně byla perioda časovače asi 54.9 ms (18.2 Hz), pod Windows tradičně 15.6 ms. Relativně moderním trendem je, že se systémová časová základna naschvál budit nenechá, aby šetřila napájení - a vzbudí se jenom když je příležitost, a uběhlý čas počítá podle hardwarového TSC, což je primitivní 64b registr CPU, který počítá tiky "furt dopředu". Klíčová slova v linuxu jsou tickless / dynticks.

Softwarové časové základny se lze kdykoli zeptat "kolik je hodin", a ona odpoví s rozlišením buď na milisekundu, nebo tuším 100 ns (WinAPI funkce GetSystemTime() a GetSystemTimeAsFileTime()). V zásadě si interně drží údaj, kolik bylo hodin, když byl naposledy vyvolán její interrupt časomíry, a jaký byl tehdy stav TSC, takže kdykoli se nějaký ostatní software zeptá, časová základna si prostě dopočítá, kolik zrovna je. Dotaz na TSC je softwarově "levný", je na to instrukce CPU.

Systémovou časovou základnu lze také požádat "vzbuď mě za 11m:23s" nebo "vzbuď mě v 03:34:25". V tom případě si i tickless kernel "nastaví budíka v hardwaru" a v nastaveném čase obdrží interrupt - v rámci jeho obsluhy nastaví čekajícímu procesu "runnable" flag a pošťouchne scheduler k činnosti...

Systémová softwarová časová základna má ponětí, jaký časový úsek odpovídá jednomu tiku periodického timeru (postaru) resp. jednomu tiku TSC (ponovu/tickless). Pokud zavěsíte systémovou časovou základnu na upstream NTP, tak si tuto představu či koeficient průběžně aktualizuje, případně dokáže ovlivňovat frekvenci tikání periodického timeru (postaru). Vlastní systémová časová základna žije v kernelu (odehrává se částečně v kontextu IRQ). Závěs na NTP zajišťuje user-space prográmek (serviska) - tato sleduje odchylku lokální časové základny od upstream NTP, velkou odchylku doladí jednorázově skokem, následně malé odchylky dolaďuje jemnými změnami "rychlosti běhu lokální systémové časové základny". Pro toto dolaďování parametrů běhu poskytuje časová základna WinAPI funkci SetSystemTimeAdjustment() - obdoba linuxové adjtimex().

Systémová časová základna používá hodinový takt a HW čítače/časovače, které jsou živé při běhu počítače (ve vypnutém stavu nikoli). Lokální referencí těchto různých provozních taktů a čítačů je v konečné instanci jeden konkrétní krystal na motherboardu, od kterého jsou sychronními děličkami a PLL syntezátory odvozené hodiny pro všechny sběrnice / procesor / čipset. (Sem tam nějaká periferie má šutr svůj vlastní, třeba ethernetové čipy.) Tenhle krystal není nijak zvlášť přesný a stabilní - řekněme něco jako 10^-5 až 10^-6. Proto si softwarová časová základna může nastavit dělící poměr používaného HW čítače/časovače (pokud to lze), nebo spíš jeho mírnou odchylku post-kompenzuje softwarově při přepočtech na lidský čas.

Časová základna moderních operačních systémů, a také například NTP, běží interně v UTC. Což je stupnice, která občas vloží přestupnou sekundu (nebo teoreticky taky vypustí, což se ale nikdy nestalo). Existují příbuzené stupnice, které tikají stejně rychle, ale přestupné sekundy nevyužívají, a tedy mají oproti UTC pevný offset: zmínil bych GPS time a ještě třeba TAI (kterou znám z protokolu IEEE1588=PTP).
UTC nevyužívá přechody zimní/letní čas.
Lokální časové zóny a přechody zimní/letní čas jsou záležitostí "prezentace v uživatelském rozhraní". Operační systém nabízí připravené funkce ke konverzím časové značky mezi zónami, ale systémová časová základna toto v podstatě neřeší - tiká si prostě svoje UTC.

No a ve virtualizačním prostředí lze nastavit, aby emulovaný guest-side HW RTC tiše ignoroval nastavení času při vypnutí OS ve VM guestovi, a aby namísto toho při každém zapnutí guesta emulovaný RTC převzal čas z časové základny hostitelského hypervizoru. Hypervizor může být zavěšený na NTP apod. Díky tomu má VM guest po každém zapnutí přesný čas.

Věc má nuanci. Aneb čerstvá příhoda z natáčení, aktuální Proxmox vs. aktuální Windowsy:

UNIX a Linux tradičně ukládá čas do RTC v zóně UTC.

Naopak Windows Server dodnes by default předpokládá, že RTC jede v lokální časové zóně! Je to zjevně dědictví desktopových windows a DOSu a světa IBM PC, kdy se RTC provozoval tradičně v lokální časové zóně (protože dávný OS nevěděl, že je něco jiného než lokální čas.)

Což vede k různým legracím pokud střídání času proběhne ve chvíli, kdy počítač neběží. Nebo ho obnovíte ze zálohy, která byla pořízena v opačném stavu letního/zimního času. Nebo počítač startuje z disku v read-only režimu. Windows totiž provedou přechod na letní čas ve chvíli, kdy ho "zažijí v zapnutém stavu", nebo nastartují v období letního času, aniž by měly na disku záznam, že provedly poslední proběhlý přechod.

Takže Windows Server předpokládá a používá RTC v lokální časové zóně, včetně přechodů léto/zima.

Proxmox o tom ví, pročež je by default nastavený, aby emulovaný RTC startoval s časem v lokální časové zóně.

Problém nastane ve chvíli, kdy virtuál s instancí Windows Serveru spouštíte jenom občas, podle potřeby. Takže se stane, že během přechodu zimní/letní čas je virtuál vypnutý. Při dalším startu mu Proxmox podá RTC už po přechodu se správným lokálním časem... a Windowsy ve VM guestovi si přechod provedou *znovu* - takže běží s časem posunutým o hodinu vedle :-)

Jak tomuto jevu zabránit? Osobně bych navrhoval, držet se UNIXové konvence: RTC jede v UTC.

Kupodivu není úplně snadné, přemluvit aktuální Windows Server, aby si RTC provozoval v UTC! (Nešlo to kdysi během instalace jedním kliknutím?) Je potřeba sáhnout do powershellu:

Kód: [Vybrat]

reg add "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /t REG_DWORD /d 1 /f
A v Proxmoxu ve vlastnostech VM je také třeba nastavit, že emulovaný RTC uvnitř guest VM jede v UTC.
Zvolte dotyčný guest VM -> Options -> Use local time for RTC: *No*

[Reklama]

[František Ryšánek]

K tomu bych měl dotaz, počítá si windows nějak "ticky času" že ví že běžel třeba x dní čistého času (po nějakých třeba minutových checkpointech) a pak se nastřádaný drift času při posunu systémového data v hypervizoru /biosu/nastavení času v guestovi  nějak projeví?

Pokud budu dotaz chápat v obecném slova smyslu cca takto:

Mějme časovou základnu, která je v závěsu na nějaké upstream referenci. Tento závěs zajišťuje průběžnou úpravu kalibrace = upravuje nějaký korekční parametr "lokálního oscilátoru", aby tento běžel "v průměru furt rovně, nejlépe s co nejmenším jitterem/wanderem".

Ten korekční parametr může být ladící napětí krystalového oscilátoru (VCXO), nebo třeba nějaký násobič v přesném syntezátoru (např. syntík v PHC síťovky i210 lze ladit s rozlišením tuším asi 10^-8), nebo třeba u softwarové časové základny windows lze upravovat časový úsek dwTimeAdjustment uběhlý za shůry danou periodu lpTimeIncrement. Kalibrační parametr má rozlišení 100 ns. Pokud jsou dwTimeAdjustmeint a lpTimeIncrement oba shodně 156250, běží hodiny s nulovou korekcí. Všimněte si, že rozlišení této korekce je cca 10^-5, což je poměrně hrubé rozlišení.

Ať už je mechanismus korekce jakýkoli, může jeho zpětná vazba fungovat pouze ve chvíli, kdy je k dispozici upstream reference (zdroj přesného času). Pokud zmizí upstream reference, lokální časová základna bude volnoběžet buď s poslední hodnotou kalibračního parametru, nebo třeba s průměrem za poslední den, nebo se může pokusit, predikovat další vývoj/trend kalibrace... Potíž je, že kalibrace prostého krystalu má vždy velikou náhodnou složku, zejména v závislosti na teplotě. Veliká náhodná složka, pod Windows mizerné rozlišení kalibračního parametru... a pak se v tom snažte predikovat nějaký trend :-)

Stabilitu lokální časové základny (i po zohlednění kalibrace včetně případné predikce) lze hodnotit pouze pokud je k dispozici přesná a autoritativní externí reference :-) Pokud v reálné situaci volnoběžíte, protože Vám upstream reference umřela, tak jaksi nemáte divergující odchylku podle čeho hodnotit... Lze to jedině v nějakém laboratorním testu, kde pro potřeby měření referenci samzřejmě zachováte v provozu, ale seberete zdroj času testvanému zařízení s hodnoceným oscilátorem...