Velen van ons hebben af en toe een probleem gehad met het bijhouden van nauwkeurige tijdsinstellingen op onze computers en andere apparaten, 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 dan zo nauwkeurig blijven?
De vraag- en antwoordsessie van vandaag komt tot ons dankzij SuperUser - een onderdeel van Stack Exchange, een community-gedreven groepering van Q & A-websites.
Foto met dank aan LEOL30 (Flickr) .
De vraag
SuperUser-lezer Frank Thornton wil weten hoe NTP-servers zo nauwkeurig kunnen blijven:
Ik heb gemerkt dat op mijn servers en andere machines de klokken altijd drijven, zodat ze moeten synchroniseren om nauwkeurig te blijven. Hoe blijven de NTP-serverklokken drijven en blijven ze altijd zo nauwkeurig?
Hoe slagen de NTP-servers erin om zo nauwkeurig te blijven?
Het antwoord
SuperUser-bijdrager Michael Kjorling heeft het antwoord voor ons:
NTP-servers vertrouwen op zeer nauwkeurige klokken voor nauwkeurige tijdregistratie. Een veelgebruikte tijdbron voor centrale NTP-servers zijn atoomklokken of GPS-ontvangers (onthoud dat GPS-satellieten atoomklokken aan boord hebben). Deze klokken worden als nauwkeurig gedefinieerd omdat ze een zeer exacte tijdreferentie bieden.
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 er gewoon heel goed in, nadat ze eens te horen hebben gekregen hoe laat het is, houden nauwkeurige tijd (sinds de tweede wordt gedefinieerd in termen van atomaire effecten ). In feite is het vermeldenswaard De gps-tijd verschilt van de UTC dat we meer gewend zijn te zien. Deze atoomklokken zijn op hun beurt gesynchroniseerd tegen Internationale Atoomtijd of TAI om niet alleen nauwkeurig het verstrijken van de tijd te vertellen, maar ook de tijd.
Als je eenmaal een exacte tijd hebt op een systeem dat is verbonden met een netwerk 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 uw desktopsysteem dat wordt gesynchroniseerd met een set NTP-servers.
Tegen de tijd dat u een paar nauwkeurige tijden heeft (zoals verkregen van NTP-servers of elders) en de voortgang van uw lokale klok kent (wat gemakkelijk te bepalen is), kunt u de driftsnelheid van uw lokale klok berekenen ten opzichte van de 'veronderstelde nauwkeurige " tijdsverloop. Eenmaal vergrendeld, kan deze waarde vervolgens worden gebruikt om de lokale klok continu aan te passen om ervoor te zorgen dat deze waarden rapporteert die zeer dicht bij het nauwkeurige tijdsverloop liggen, zelfs als de lokale real-time klok zelf zeer onnauwkeurig is. Zolang uw lokale klok niet hoog staat grillig , dit zou het mogelijk moeten maken enige tijd nauwkeurig de tijd bij te houden, zelfs als uw stroomopwaartse tijdsbron om welke reden dan ook niet beschikbaar is.
Sommige NTP-clientimplementaties (waarschijnlijk de meeste ntpd-daemon of systeemservice-implementaties) doen dit, en andere (zoals ntpd's metgezel ntpdate die de klok gewoon één keer zet) doen dit niet. Dit wordt gewoonlijk een drift-bestand omdat het voortdurend een mate van klokdrift opslaat, maar strikt genomen niet als een specifiek bestand op schijf hoeft te worden opgeslagen.
In NTP is Stratum 0 per definitie een nauwkeurige tijdsbron. Stratum 1 is een systeem dat een Stratum 0-tijdsbron als tijdsbron gebruikt (en dus iets minder nauwkeurig is dan de Stratum 0-tijdsbron). Stratum 2 is weer iets minder nauwkeurig dan Stratum 1 omdat het zijn tijd synchroniseert met de Stratum 1-bron enzovoort. In de praktijk is dit verlies aan nauwkeurigheid zo klein dat het in alle gevallen, behalve in de meest extreme gevallen, volledig te verwaarlozen is.
Iets toe te voegen aan de uitleg? Geluid uit in de reacties. Wilt u meer antwoorden lezen van andere technisch onderlegde Stack Exchange-gebruikers? Bekijk hier de volledige discussiethread .
