[EDITOVAT] Velký přepis s odkazy, protože jsem si právě poznamenal starou odpověď z paměti.
Krátká odpověď:ne. Z běžného operačního systému na platformě x86/x64 dnes není možné dosáhnout přesnosti téměř milisekund.
ODPOVĚDNOST Toto je odpověď pro laiky, protože jsem obyčejný správce systému s běžným pohledem správce systému na počítače. Profesionální úroveň znalostí měření času se pravděpodobně vyskytuje u některých vývojářů jádra a hardwarových architektů.
Dlouhá odpověď:
Někde se začít musí. Udělám to shora dolů, počínaje aplikacemi pohybujícími se dolů směrem k oscilátoru (oscilátorům).
Prvním problémem není mít časomíru na jednom počítači, ale dosáhnout toho, aby se prostředí jako celek dohodlo na jakékoli časomíře, kterou máte. Jaká časomíra? Ukazuje se, že v dnešní době existuje několik způsobů, jak udržet čas v počítači. Nejvíce vidíme systémový čas (zobrazený v jednom z rohů obrazovky). Začněme předstíráním, že je to tak jednoduché a o pár odstavců níže to zkomplikujeme.
Chceme, aby byl systémový čas správný a aby byl jednotný na všech našich počítačích. Potřebujeme způsob, jak to sdělit z důvěryhodného zdroje na tak podrobné úrovni, abychom splnili naše požadavky, ať už jsou jakékoli.
Udělejme náš požadavek na úroveň tolerance 1 ms, to znamená, že se náš čas může v našem prostředí lišit o 1 ms nebo mineme kritický cíl. Pojďme konkrétně a podívejme se, co pro nás může Microsoft udělat.
S výjimkou zastaralých, jako je NT, nativní systém Windows spouští své měření času založené buď na zjednodušeném ntp (počítače připojené k doméně počínaje XP/2003) nebo zjednodušeném sntp (počítače nepřipojené k doméně počínaje Win2k) - díky @Ryan za vytipování tohoto detailu . Microsoft si při implementaci měření času stanovil dva cíle, z nichž žádný nezahrnuje naši požadovanou úroveň přesnosti:
"Nezaručujeme a nepodporujeme přesnost služby W32Time mezi uzly v síti. Služba W32Time není plnohodnotným řešením NTP, které splňuje potřeby aplikací citlivých na čas. Služba W32Time je primárně navržena proveďte následující:
- Zajistěte fungování ověřovacího protokolu Kerberos verze 5.
- Poskytněte čas pro synchronizaci klientských počítačů.
Služba W32Time nemůže spolehlivě udržovat čas synchronizace v rozsahu jedné až dvou sekund. Takové tolerance jsou mimo specifikaci návrhu služby W32Time.“
OK. Za předpokladu, že provozujeme váš zásobník služeb na více než jednom počítači a máme úroveň tolerance časového měření blížící se 1 ms pro korelaci událostí, je to docela zklamání. Pokud zásobník služeb obsahuje dva počítače, nemůžeme ve skutečnosti vůbec používat nativní měření času systému Windows. Ale když už jsme u toho, pojďme zdůraznit jeden nebo dva klíčové body o nativním měření času ve Windows a zahrnout několik důkladné dokumentace:
Pokud máte AD, všimněte si, že čas v dané doméně bude synchronizován z role emulátoru primárního řadiče domény, podle toho, který DC ji má. Přivedení správného času do domény tak musí probíhat prostřednictvím řadiče domény s rolí emulátoru primárního řadiče domény. Pokud v doménové struktuře s více doménami, převádí se to na emulátor primárního řadiče domény kořenové domény doménové struktury. Odtud je čas distribuován primárně do emulátorů PDC subdomén a do každého člena domény vějířovitým způsobem (s určitými výhradami). Tento proces je zdokumentován zde. Ještě podrobnější informace zde
OK. Co můžeme dělat?
Pro začátek potřebujeme jeden nebo druhý přesnější způsob synchronizace času v celém prostředí. Za předpokladu, že nemůžeme spustit Linux ntpd nebo ntpd pro Windows, můžete se podívat na sharewarového klienta s názvem Tardis, ale pravděpodobně existuje mnoho dalších, které můžete vyzkoušet.
Tardis jsme provozovali na Win2k3 serveru běžícím jako PDC Emulator, který měl CMOS hodiny s opravdu velkým zkreslením, z nevysvětlitelných historických důvodů jsme neměli jinou možnost, než z něj synchronizovat celou síť. Nyní byl k velké radosti nahrazen dedikovaným linuxovým ntpd přinášejícím čas z atomových hodin zvenčí, ale Tardis nás tehdy a tam obdivuhodně zachránil. Nevím však, zda by vám to mohlo pomoci dosáhnout větší přesnosti než nativní systém Windows.
Předpokládejme však, že od tohoto okamžiku jsme přišli (nás) na to, jak implementovat dokonalou náhradní synchronizaci času sítě. Díky své přirozené šikovnosti má kapacitu pro úrovně tolerance pod jednu milisekundu. Zavedli jsme to, abychom vynutili, jak naše AD očekává, že se čas bude šířit sítí.
Znamená to, že můžeme získat přesnou diagnostiku operačních systémů a mikroslužeb s přesností blížící se milisekundám?
Podívejme se, jak operační systémy na architektuře x86/x64 plánují čas procesoru.
Používají přerušení, což jsou mnohotvárná zvířata bohatá na archeologické látky. Operační systém však není sám ve své touze přerušit. Hardware si přeje také přerušit a má k tomu prostředky! (Ahoj, klávesnice) A operační systémy spolu hrají.
Tady se to komplikuje a vyřeším to přílišným zjednodušením. Otázky? Skrčím se, kryji a ukazuji vás na naprosto vynikající pojednání na toto téma. (Pokud hledáte milisekundy na platformě Windows, měli byste si to opravdu přečíst..) Aktualizovaná verze pro Win8.1/Win2012r2 se údajně připravuje, ale zatím se neobjevilo žádné datum vydání.
Dobře, přerušuje. Kdykoli by se v OS mělo něco stát, přerušení spustí akci, která následuje. Akce je shluk instrukcí načtených z jádra, které lze provádět mnoha různými způsoby. Pointa je, že navzdory tomu, že k přerušení dochází v čase, který lze určit s větší či menší přesností v závislosti na hardwarové architektuře a zpracování přerušení v jádře, přesný čas, ve kterém nastanou následující části provádění, obecně nemůže. Specifická sada instrukcí může být provedena brzy po přerušení nebo pozdě, může být provedena v předvídatelném pořadí nebo ne, může být obětí chybného hardwaru nebo špatně napsaných ovladačů ovlivňujících latence, které je těžké vůbec rozpoznat. Většinu času člověk prostě neví. Časové razítko na úrovni milisekund, které se zobrazuje v následujícím souboru protokolu – je velmi přesné, ale je přesné, pokud jde o to, kdy k události došlo?
Zastavme se krátce u přerušení měření času. Přerušení přichází s úrovní priority, nejnižší úroveň je tam, kde uživatelské aplikace (jako je standardní služba) získávají svůj procesorový čas. Ostatní (vyšší) úrovně jsou vyhrazeny pro hardware a pro práci s jádrem. Pokud dojde k přerušení na úrovni vyšší než nejnižší, systém bude předstírat, že žádná přerušení s nižší prioritou také ve frontě neexistují (dokud nebudou ošetřena přerušení s vyšší prioritou). Běžné aplikace a služby běžící tímto způsobem budou poslední v řadě po dobu procesoru. Naproti tomu téměř nejvyšší priorita je dána přerušení hodin. Aktualizace času se téměř vždy provede v systému. Toto je téměř zločinné zjednodušení toho, jak to všechno funguje, ale slouží účelu této odpovědi.
Aktualizace času se ve skutečnosti skládá ze dvou úkolů:
-
Aktualizace systémového času / AKA nástěnné hodiny / AKA, co říkám, když se mě někdo zeptá, kolik je hodin / AKA ta věc ntp trochu pohrává tam a zpět vzhledem k okolním systémům.
-
Aktualizace počtu tiků, která se používá například při měření trvání při provádění kódu.
Ale ať už jde o čas zdi nebo počet tiků, odkud systém čas bere? Velmi záleží na hardwarové architektuře. Někde v hardwaru tiká jeden nebo několik oscilátorů a toto tikání je přeneseno jednou z několika možných cest do rozhraní pro kontakt s jádrem, protože s větší či menší přesností a přesností aktualizuje svůj čas stěny a počet tiků.
Existuje několik návrhových modelů pro umístění oscilátoru ve vícejádrovém systému, hlavní diferenciátor se zdá být synchronní vs asynchronní umístění. Ty spolu s příslušnými výzvami k přesnému měření času jsou popsány například zde.
Stručně řečeno, synchronní měření času má jeden referenční takt na vícejádro, který dostává svůj signál distribuovaný do všech jader. Asynchronní měření času má jeden oscilátor na jádro. Stojí za zmínku, že nejnovější vícejádrové procesory Intel (Haswell) používají určitou formu synchronního designu pomocí sériové sběrnice nazývané „QuickPath Interconnect“ s „Forwarded Clocking“, ref. datový list. Forwarded Clocking je popsán tak, že laik (já) to zde může rychle povrchně pochopit.
Dobře, takže se vším tím nerderismem z cesty (který sloužil k tomu, aby ukázal, že měření času je složitý praktický úkol s mnoha živou historií), podívejme se ještě blíže na zacházení s přerušeními.
Operační systémy řeší přerušení pomocí jedné ze dvou odlišných strategií:ticking nebo tickless. Vaše systémy používají jedno nebo druhé, ale co tyto pojmy znamenají?
Ticking kernels posílat přerušení v pevných intervalech. Operační systém nemůže měřit čas s jemnějším rozlišením, než je interval tikání. I potom může skutečné zpracování, které je součástí provádění jedné nebo několika akcí, obsahovat zpoždění větší, než je interval tikání. Zvažte například distribuované systémy (jako jsou mikroslužby), kde by zpoždění spojená s meziservisními hovory mohla spotřebovat relativně hodně času. Přesto bude každá sada instrukcí spojena s jedním nebo několika přerušeními měřenými operačním systémem s rozlišením, které není jemnější, než je doba tikání jádra. Doba tikání má základní hodnotu, ale může být alespoň ve Windows snížena na vyžádání individuální aplikací. Jedná se o akci spojenou nejen s výhodami, ale také s náklady a nese s sebou docela dost drobného písma.
Takzvaná jádra bez tickless (které mají velmi nepopisný název) jsou relativně novým vynálezem. Tickless kernel nastavuje čas tikání v proměnných intervalech (tak dlouho, jak je to možné do budoucnosti). Důvodem je to, že operační systém dynamicky umožňuje procesorovým jádrům přejít do různých úrovní spánku tak dlouho, jak je to možné, s jednoduchým účelem šetřit energii. "Různé úrovně" zahrnují zpracování instrukcí plnou rychlostí, zpracování sníženou rychlostí (tj. nižší rychlost procesoru) nebo nezpracování vůbec. Různá jádra mohou pracovat různými rychlostmi a jádro bez tickless se snaží nechat procesory být co nejméně aktivní, a to i v případech, kdy se řadí instrukce k jejich spouštění v dávkách přerušení. Stručně řečeno, různá jádra ve víceprocesorovém systému se mohou vzájemně pohybovat v čase. To samozřejmě způsobuje zmatek s dobrým udržováním času a je to zatím nevyřešený problém s novějšími architekturami procesorů pro úsporu energie a bez tikových jader, která jim umožňují efektivně šetřit energii. Porovnejte to s tikajícím jádrem (statický tickový interval), které neustále probouzí všechna procesorová jádra, bez ohledu na to, zda přijímají skutečnou práci nebo ne, a kde měření času přináší určitou míru nepřesnosti, ale v relativně spolehlivé míře ve srovnání s jádry bez tiků.
Standardní doba tikání systému Windows - to je systémové rozlišení - je 15,6 ms až do Windows 8/2012, kde je výchozí chování bez tikání (ale lze jej vrátit do tikajícího jádra). Předpokládám, že výchozí doba tikání Linuxu závisí na kompilaci jádra, ale tento výklenek je zcela mimo moji zkušenost (a tuto také), takže možná budete chtít znovu zkontrolovat, zda jste na něm závislí. Já věřím, že linuxová jádra jsou kompilována bez tickless od 2.6.21 a mohou být zkompilována s různými příznaky optimalizujícími chování bez tickless (a z nichž si pamatuji jen několik variant no_hz).
Tolik o holých kovových systémech. Ve virtuálních systémech se to zhoršuje, protože spory VM a hypervisoru různými způsoby extrémně ztěžují přesné měření času. Zde je přehled pro VMware a zde je jeden pro RHEL KVM. Totéž platí pro distribuované systémy. Cloudové systémy jsou ještě obtížnější, protože se ani nepřiblížíme k tomu, abychom viděli skutečné hypervizory a hardware.
Abych to uzavřel, získávání přesného času ze systému je vícevrstvý problém. Z pohledu vysoké úrovně zdola nahoru musíme vyřešit:Interní synchronizaci času mezi hardwarem a jádrem, zpracování přerušení a zpoždění při provádění instrukcí, které si přejeme, pokud jsou ve virtuálním prostředí nepřesnosti díky zapouzdření druhé vrstvy OS, synchronizaci času mezi distribuovanými systémy.
Proto v tomto bodě historie výpočetní techniky nezískáme přesnost na úrovni milisekund z architektury x86/x64, alespoň pokud nebudeme používat žádný z běžných operačních systémů.
Ale jak blízko se můžeme dostat? Nevím a mezi různými systémy by se to mělo velmi lišit. Odhalit nepřesnosti ve vlastních specifických systémech je skličující úkol. Stačí se podívat na to, jak Intel navrhuje provádět srovnávání kódu, abychom viděli, že běžné systémy, jako jsou ty, které shodou okolností spravuji, jsou z tohoto pohledu velmi mimo kontrolu.
Nemám ani pomyšlení na dosažení "Veškerá optimalizace napájení, technologie Intel Hyper-Threading, frekvenční škálování a funkce turbo režimu byly vypnuty" v kritických systémech, mnohem méně se pohrávat s obaly kódu v C a spouštět dlouhodobé testy pro získání následných odpovědí. Jen se je snažím udržet naživu a dozvědět se o nich co nejvíce, aniž bych je příliš rušil. Děkuji časové razítko, vím, že vám nemohu plně věřit, ale vím, že nemáte příliš mnoho sekund. Když je skutečná přesnost v milisekundách důležitá, jedno měření nestačí, ale k ověření vzoru je potřeba větší počet měření. Co ještě můžeme udělat?
Nakonec je zajímavé podívat se na to, jak si lidé s operačním systémem v reálném čase myslí latenci přerušení. V práci je také velmi vzrušující alternativa synchronizace času, kde je zveřejněno poměrně dost zajímavých statistik, metodologie a whitepaperů. Přidejte k tomu budoucí hardwarovou architekturu a vývoj jádra a za pár let už tato věc s přesností měření času nemusí být takový problém. Člověk může doufat.