Hoe kunnen NTP-servers zo nauwkeurig beheren?
Velen van ons hebben af en toe een probleem gehad met onze computers en andere apparaten met behoud van nauwkeurige tijdsinstellingen, maar een snelle synchronisatie met een NTP-server maakt alles weer goed. Maar als onze eigen apparaten de nauwkeurigheid kunnen verliezen, hoe kunnen NTP-servers zo nauwkeurig blijven?
De Question & Answer-sessie van vandaag komt tot ons dankzij SuperUser - een onderdeel van Stack Exchange, een gemeenschapsgedreven groep van Q & A-websites.
Foto met dank aan LEOL30 (Flickr).
De vraag
SuperUser-lezer Frank Thornton wil weten hoe NTP-servers zo accuraat kunnen blijven:
Ik heb gemerkt dat op mijn servers en andere machines de klokken altijd afdrijven, zodat ze moeten worden gesynchroniseerd om accuraat te blijven. Hoe de klokken van de NTP-server blijven ronddrijven en altijd zo accuraat blijven?
Hoe kunnen de NTP-servers zo nauwkeurig blijven??
Het antwoord
SuperUser-bijdrager Michael Kjorling heeft het antwoord voor ons:
NTP-servers vertrouwen op zeer nauwkeurige klokken voor nauwkeurige tijdregistratie. Een algemene tijdsbron voor centrale NTP-servers zijn atoomklokken of GPS-ontvangers (onthoud dat GPS-satellieten atomaire klokken aan boord hebben). Deze klokken worden als nauwkeurig gedefinieerd omdat ze een zeer exacte tijdsreferentie verschaffen.
Er is niets magisch aan GPS of atoomklokken waardoor ze je precies vertellen hoe laat het is. Vanwege de manier waarop atoomklokken werken, zijn ze gewoon heel goed in, nadat eenmaal is verteld hoe laat het is, bewaring nauwkeurige tijd (aangezien de tweede is gedefinieerd in termen van atomaire effecten). In feite is het vermeldenswaard dat GPS-tijd verschilt van de UTC die we meer gewend zijn te zien. Deze atoomklokken zijn op hun beurt gesynchroniseerd met International Atomic Time of TAI om niet alleen nauwkeurig het verloop van de tijd te vertellen, maar ook de tijd.
Zodra u een exacte tijd hebt op een systeem dat op een netwerk is aangesloten, zoals internet, is het een kwestie van protocolengineering die de overdracht van precieze tijden tussen hosts via een onbetrouwbaar netwerk mogelijk maakt. In dit opzicht verschilt een Stratum 2 (of verder van de werkelijke tijdbron) NTP-server niet van het synchroniseren van uw desktopsysteem met een set NTP-servers.
Tegen de tijd dat u een paar nauwkeurige tijden hebt (zoals verkregen van NTP-servers of elders) en de voortgangsgraad van uw lokale klok kent (die gemakkelijk te bepalen is), kunt u de driftsnelheid van uw lokale klok berekenen ten opzichte van de "geloofde nauwkeurigheid" " tijdsverloop. Eenmaal ingesloten, kan deze waarde vervolgens worden gebruikt om de lokale klok continu aan te passen zodat deze waarden zeer dicht bij de nauwkeurige passage van tijd rapporteert, zelfs als de lokale realtimeklok zelf hoogst onnauwkeurig is. Zolang je lokale klok niet hoog is grillige, dit zou het mogelijk moeten maken om enige tijd nauwkeurige tijd aan te houden, zelfs als je stroomopwaartse tijdbron om welke reden dan ook niet meer beschikbaar is.
Sommige NTP-clientimplementaties (waarschijnlijk de meeste ntpd daemon- of systeemdienstimplementaties) doen dit, en anderen (zoals ntpd's metgezel-ntddate die eenvoudig de klok eenmaal instelt) doen dat niet. Dit wordt meestal a driftbestand omdat het voortdurend een maat voor de kloksnelheid opslaat, maar strikt genomen hoeft het niet als een specifiek bestand op schijf te worden opgeslagen.
In NTP is Stratum 0 per definitie een nauwkeurige tijdbron. Stratum 1 is een systeem dat een Stratum 0-tijdbron als de tijdbron gebruikt (en is dus iets minder nauwkeurig dan de Stratum 0-tijdbron). Stratum 2 is weer iets minder nauwkeurig dan Stratum 1 omdat het de tijd synchroniseert met de Stratum 1-bron enzovoort. In de praktijk is dit verlies aan nauwkeurigheid zo klein dat het volledig verwaarloosbaar is in bijna alle extreme gevallen.
Heb je iets toe te voegen aan de uitleg? Geluid uit in de reacties. Wilt u meer antwoorden van andere technisch onderlegde Stack Exchange-gebruikers lezen? Bekijk hier de volledige discussiethread.
