Hur hanterar NTP-servrar att hålla sig så exakt?
Många av oss har haft enstaka problem med våra datorer och andra enheter som behåller exakta tidsinställningar, men en snabb synkronisering med en NTP-server gör allt bra igen. Men om våra egna enheter kan förlora noggrannhet, hur lyckas NTP-servrarna hålla sig så exakta?
Dagens Question & Answer-session kommer till oss med tillstånd av SuperUser-en indelning av Stack Exchange, en community-driven gruppering av Q & A-webbplatser.
Foto med tillstånd av LEOL30 (Flickr).
Frågan
SuperUser-läsaren Frank Thornton vill veta hur NTP-servrar kan förbli så exakta:
Jag har märkt att på mina servrar och andra maskiner glider klockorna alltid så att de måste synkronisera för att förbli korrekta. Hur håller NTP-serverns klockor sig från drift och förbli alltid så exakt?
Hur lyckas NTP-servrarna förbli så exakta?
Svaret
SuperUser-bidragaren Michael Kjorling har svaret för oss:
NTP-servrar är beroende av mycket noggranna klockor för precisionstidning. En vanlig källa för centrala NTP-servrar är atomklockor, eller GPS-mottagare (kom ihåg att GPS-satelliter har atomur ombord). Dessa klockor definieras som exakta eftersom de ger en mycket exakt tidsreferens.
Det finns inget magiskt om GPS eller atomklockor som får dem att berätta exakt vilken tid det är. På grund av hur atomklockor fungerar, är de helt enkelt mycket bra på att en gång ha blivit tillsagd vilken tid det är, förvaring exakt tid (eftersom den andra definieras när det gäller atom effekter). Faktum är att det är värt att notera att GPS-tiden skiljer sig från UTC som vi brukar se. Dessa atomklockor är i sin tur synkroniserade mot International Atomic Time eller TAI för att inte bara korrekt berätta tidens gång utan också de tid.
När du har en exakt tid på ett system som är anslutet till ett nätverk som Internet, handlar det om protokollteknik som möjliggör överföring av exakta tider mellan värdar över ett opålitligt nätverk. I detta avseende är en Stratum 2 (eller längre från den aktuella tidskällan) NTP-servern annorlunda än din skrivbordssynkronisering mot en uppsättning NTP-servrar.
När du har några korrekta tider (som erhållits från NTP-servrar eller någon annanstans) och vet hur snabbt din lokala klocka går framåt (vilket är lätt att bestämma), kan du beräkna din lokala klockas drivhastighet i förhållande till den "troliga noggranna " tidens gång. När det är låst in kan det här värdet användas för att kontinuerligt justera den lokala klockan så att den rapporterar värden väldigt nära den korrekta tiden, även om den lokala realtidsklockan själv är mycket felaktig. Så länge din lokala klocka inte är hög oregelbunden, Detta borde möjliggöra att hålla rätt tid för en viss tid även om din uppströms tidskälla blir otillgänglig av någon anledning.
Några NTP-klientimplementeringar (förmodligen de flesta ntpd-demoner eller systemtjänstimplementeringar) gör det här, och andra (som ntpds följeslagare ntpdate som helt enkelt sätter klockan en gång) gör det inte. Detta kallas vanligtvis som a driftfil eftersom det ständigt lagrar ett mått på klockdrift, men strängt taget behöver den inte lagras som en specifik fil på disken.
I NTP är Stratum 0 per definition en exakt tidskälla. Stratum 1 är ett system som använder en Stratum 0-tidskälla som sin tidskälla (och är således något mindre noggrann än Stratum 0-tidskällan). Stratum 2 är en gång mindre noggrann än Stratum 1 eftersom den synkroniserar sin tid mot Stratum 1-källan och så vidare. I praktiken är denna förlust av noggrannhet så liten att den är helt försumbar i alla utom de mest extrema fallen.
Har du något att lägga till förklaringen? Ljud av i kommentarerna. Vill du läsa mer svar från andra tech-savvy Stack Exchange-användare? Kolla in hela diskussionsgängan här.
