K předchozímu viz např. zde bod 5.
Díky za výživný odkaz - pro mě osobně výživný od A do Z.
Konkrétně k bodu 5:
takže "bývaly doby, kdy DC běžící ve VM (Hyper-V) uměl přebírat čas od hostitele a distribuce času v doméně takto fungovala. Ty doby jsou pryč. Odteď si chce DC ve VM správcovat čas striktně sám, brát ho z upstream NTP serveru." Přestože je to obecně z hlediska časomíry ve virtualizovaném prostředí možné méně vhodná varianta, dodávám já.
Líbí se mi, jak distribuce času ve Windows doméně funguje bezpracně, samospádem, včetně krypto-ošetření. Dokonce mám pocit, že W32time s každou novou generací Windows trochu dospěje. Bravo. Tzn. jenom na okraj chci zmínit, že to může fungovat taky mimo doménu, dokonce jako časová serviska na NTP klientech (včetně DC!) nemusí být použita W32time, ale open-source ntpd (Windows build).
Každopádně pokud NTP klient běží ve VM, ať už je na bázi W32time nebo ntpd, týkají se ho obecné nectnosti virtualizovaného prostředí pokud se týče časomíry. K tématu existuje obecný
whitepaper od Meinbergů - autor Martin Burnicki je jejich dlouholetý klíčový vývojář ovladačů pro Windows a Linux. Jeho univerzální driver pod Windows, co se chytí cca od NT po Win10 na všechen jejich hardware (ISA/PCI/USB) je takový nepravděpodobný drahokam. Ten člověk ví o čem mluví. A mluví o spojitosti běhu softwarové časové základny v guest OS, která záleží na "spojitosti virtualizace" (ideálně vyhrazené CPU jádro pro guesta) a zejména na přesnosti/spojitosti/spolehlivosti doručování interruptů HW časovače - což není zrovna triviální požadavek vzhledem k tomu, že guest nevlastní fyzický čipset, ve kterém se tyto časovače vyskytují (vlastní nanejvýš CPU TSC a LAPIC timer, což je myslím trochu málo, on totiž není časovač jako časovač.)
Tradiční moudro bývalo, že ve virtuálu stojí časomíra za vyliž. (Což se na nenáročném klientovi ještě zkousne, ale na NTP serveru ztuha.) Nějakou dobu už ale slýchám dovětek, že moderní verze hypervizorů v tomto směru učinily značný pokrok. Každopádně mi připadá jako zdravý a systematický postup, použít nativní podporu HV pro časomíru, tzn. nakonfigurovat guesty, ať si berou čas 1:1 od hostitele, který jediný má pod palcem fyzické železo a může provozovat košer časovou základnu, včetně závěsu na vnější NTP, PTP, PPS, co já vím (záleží co HV software podporuje). Druhá možnost je, nechat guesta, ať si spravuje čas sám, pokud se HV vynasnaží, neházet mu v tom klacky pod nohy - viz doručování timer interruptů.
Zcela souhlasím s tím, co už tady napsali jiní: bacha ať časovou základnu guesta nedolaďují na střídačku dva různé mechanismy. Pak se totiž "perou", přestane existovat jediná a jasná zpětnovazební dolaďovací smyčka.
Pokud se týče doladění skokem vs. spojitě, ta volba je samozřejmě kompromis, uvědomte si že při skokovém doladění může čas poskočit *dozadu*, což je v mnoha případech průser. V jiných případech je kriticky žádoucí, aby přesný čas seděl hned po doladění. Záleží na aplikaci = způsobu použití, oblasti nasazení. Je třeba si uvědomit, že pro volnoběh (softwarové) časové základny lokálního OS mezi dvěma "olíznutími upstreamu" je třeba dolaďovat frekvenci tohoto volnoběhu, a že nějaká reziduální nepřesnost bude nastávat pravidelně, ať už dolaďujeme výhradně spojitě nebo výhradně skokem.
Úplně přesnému času se lze přiblížit několika způsoby:
- dodatečným hardwarem a třeba ještě specializovaným API, které z toho hardwaru bude tahat časové značky
- slušně přesnou synchronizaci lokálního systémového času OS dokáže poskytnout PPS vstup, ale ten pod Windows pokud vím nelze na generickém PC HW zavést (pod Linuxem ano, skrz sériový či paralelní port, nebo skrz síťovku s HW podporou PTP)
- což mi připomíná, že z hlavy nevím, jak často dolaďuje frekvenci SW časomíry OS Meinbergovic serviska běžící v přítomnosti Meinbergovic přesných HW hodin (PCI-e) - možná každou sekundu? Každopádně se to té systémové PPSce bude dost blížit
- v národních laboratořích etalonu času se vyskytují extrémisti, kteří si fázově zavěsí centrální oscilátor PC motherboardu na vnější frekvenční normál, takže pak servosmyčka časomíry v OS rychle zkonverguje ke konkrétní hodnotě, která se dál už prakticky nemění (protože ten mizerný šutr na motherboardu už nevandruje)
Závěrem obligátní poznámka: softwarová systémová časomíra pod Windows má přesnost poměrně omezenou reálnou granularitou časových značek. Za starých časů to bývalo 15.6 ms (perioda scheduleru), tuším od Win7 je to 1 ms, netuším zda v nejnovějších 10/2016 se to třeba dál nezlepšilo. V Linuxu už drahně let není problém, aby ntpd vykazoval reziduální offset v nízkých jednotkách mikrosekund pokud má PPS, nebo cca 20-50 us pokud bere čas po nezatížené LANce od kvalitního stratum 1.
25 Odpovědí
9944 Zhlédnutí