Förbättringar av tidsprecision för Windows Server 2016

Windows Server 2016 har förbättrat de algoritmer som används för att korrigera tid och villkora den lokala klockan att synkronisera med Coordinated Universal Time (UTC). NTP (Network Time Protocol) använder fyra värden för att beräkna tidsförskjutningen baserat på tidsstämplarna för klientens begäran/svar och serverbegäran/svar. Nätverk är dock bullriga och det kan finnas toppar i data från NTP på grund av nätverksbelastning och andra faktorer som påverkar nätverksfördröjningen. Windows Server 2016-algoritmer beräknar det här bruset med hjälp av flera olika tekniker, vilket resulterar i en stabil och korrekt klocka. Källan som vi använder för korrekt tid refererar också till ett förbättrat API, vilket ger oss bättre lösning. Med dessa förbättringar kan vi uppnå 1 ms noggrannhet när det gäller UTC i en domän.

Hyper-V

Windows Server 2016 har förbättrat tjänsten Hyper-V TimeSync. Förbättringarna omfattar en mer exakt starttid på den virtuella datorn (VM) eller återställning av den virtuella datorn och korrigering av avbrottsfördröjning för exempel som tillhandahålls till Windows-tidstjänsten (W32Time). Den här förbättringen gör att vi kan hålla oss inom 10 μs från värden med en rot-medelvärdesruta (vilket indikerar varians) på 50μs, även på en dator med 75% belastning. Mer information finns iHyper-V arkitektur.

Den Stratum-nivå som värden rapporterar till gästen är mer transparent. Tidigare skulle värden presentera en fast Stratum på 2, oavsett dess noggrannhet. Med ändringarna i Windows Server 2016 rapporterar värden en Stratum 1 som är större än värd-Stratum, vilket ger bättre tid för virtuella gäster. Värden Stratum bestäms av W32Time på normalt sätt baserat på källtiden. Domänanslutna Windows Server 2016-gäster hittar den mest exakta klockan i stället för att använda värddatorns klocka som standard. Därför rekommenderar vi att du inaktiverar inställningen Hyper-V tidsprovider manuellt för datorer som deltar i en domän i Windows Server 2012 R2 och tidigare.

Monitoring

Prestandaövervakarens räknare har lagts till. Dessa räknare gör det möjligt för dig att grunda, övervaka och felsöka tidsnoggrannhet. I följande tabell visas räknarna.

De första tre räknarna syftar på scenarier för felsökning av noggrannhetsproblem. Mer information finns i avsnittet Felsöka tidsnoggrannhet och NTP senare i den här artikeln. De tre sista räknarna täcker NTP-serverscenarier och är användbara när du fastställer belastningen och baserar din aktuella prestanda.

Konfigurationsuppdateringar per miljö

I följande tabell beskrivs ändringarna i standardkonfigurationen mellan Windows Server 2016 och tidigare versioner för varje roll. Inställningarna för Windows Server 2016 och Windows 10 Anniversary Update (version 14393) är nu unika, varför de visas som separata kolumner.

Effekten av ökad frekvens för polling och klockuppdateringar

För att ge mer exakt tid ökar standardvärdena för avsökningsfrekvenser och klockuppdateringar, vilket gör att vi kan göra små justeringar oftare. Den här ändringen orsakar mer UDP-/NTP-trafik (User Datagram Protocol). Dessa paket är små, så det bör vara liten eller ingen effekt på bredbandslänkar. Fördelen är att tiden bör vara bättre på ett bredare utbud av maskinvara och miljöer.

Om du ökar avsökningsfrekvensen för batteribaserade enheter kan det orsaka problem. Batterienheter lagrar inte tiden när de är avstängda. När de återupptas kan de kräva frekventa justeringar av klockan. Om du ökar avsökningsfrekvensen blir klockan instabil och kan också använda mer ström. Vi rekommenderar att du inte ändrar klientens standardinställningar.

Domänkontrollanter (DCs) bör påverkas minimalt även med den multiplicerade effekten av de ökade uppdateringarna från NTP-klienter i en Active Directory-domän. NTP har en mycket mindre resursförbrukning jämfört med andra protokoll och en marginell effekt. Det är mer troligt att du når gränserna för andra domänfunktioner innan du påverkas av de ökade inställningarna för Windows Server 2016. Active Directory använder säker NTP, vilket tenderar att synkronisera tid mindre exakt än enkel NTP. Vi har verifierat att det kan skala upp till klienter som är två Stratum bort från den primära domänkontrollanten (PDC).

Som en konservativ plan bör du reservera 100 NTP-begäranden per sekund per kärna. Med en domän som består av fyra domänkontrollanter med fyra kärnor vardera bör du till exempel kunna hantera 1 600 NTP-begäranden per sekund. Om du har 10 000 klienter konfigurerade för synkroniseringstid en gång var 64:e sekund och begäranden tas emot enhetligt över tid, skulle du se 10 000/64, eller cirka 160 begäranden/sekund, spridda över alla domänkontrollanter. Det här beloppet ligger enkelt inom våra 1 600 NTP-begäranden per sekund baserat på det här exemplet. Dessa planeringsrekommendationer är konservativa och beror till stor del på nätverket, processorhastigheter och belastningar. Som alltid, fastställ baslinjen och testa inom dina miljöer.

Om dina domänkontrollanter körs med en betydande CPU-belastning, större än 40%, tillför denna belastning nästan säkert brus i NTP-svar och påverkar din tidsnoggrannhet i din domän. Återigen måste du testa i din miljö för att förstå de faktiska resultaten.

Tidsnoggrannhetsmätningar

För att mäta tidsnoggrannheten för Windows Server 2016 använde vi olika verktyg, metoder och miljöer. Du kan använda dessa tekniker för att mäta och finjustera din miljö och avgöra om noggrannhetsresultaten uppfyller dina krav.

Methodology

Vår domän källklocka bestod av två NTP-servrar med hög precision med GPS-maskinvara. Vi använde också en separat referenstestmaskin för mätningar, som också hade GPS-maskinvara med hög precision installerad från en annan tillverkare. För vissa av testerna behöver du en korrekt och tillförlitlig klockkälla som ska användas som referens utöver din domänklockakälla.

Vi använde fyra olika metoder för att mäta noggrannhet med både fysiska och virtuella datorer. Flera metoder tillhandahöll oberoende metoder för att verifiera resultaten.

1. Mät den lokala klockan, som villkoras av w32tm, mot vår referenstestmaskin, som har separat GPS-maskinvara.

2. Mät NTP-ping från NTP-servern till klienter med hjälp W32tm av stripchart.

3. Mät NTP-ping från klienten till NTP-servern med hjälp av stripchart.W32tm

4. Mät Hyper-V resultat från värden till gästen med hjälp av tidsstämpelräknaren (TSC). Den här räknaren delas mellan både partitioner och systemtiden i båda partitionerna. Vi beräknade skillnaden mellan värdtiden och klienttiden på den virtuella datorn. Sedan använde vi TSC-klockan för att interpolera värdtiden från gästen eftersom mätningarna inte sker samtidigt. Dessutom använde vi den tidssegmenterade volymklockan för att räkna ut fördröjningar och svarstider i API:et.

W32tm är inbyggt, men de andra verktygen som vi använde under testningen är tillgängliga för Microsoft-lagringsplatsen på GitHub som öppen källkod för testning och användning. Mer information om hur du använder verktygen för att utföra mätningar finns i Wiki för Windows Tidskalibreringsverktyg.

Testresultaten som visas är en delmängd av de mått som vi gjorde i en av testmiljöerna. De illustrerar noggrannheten som upprätthålls i början av tidshierarkin och den underordnade domänklienten i slutet av tidshierarkin. Dessa resultat jämförs med samma datorer i en 2012-baserad topologi för jämförelse.

Topology

Som jämförelse testade vi topologier baserade på Windows Server 2012 R2 och Windows Server 2016. Båda topologierna består av två fysiska Hyper-V värddatorer som refererar till en Windows Server 2016-dator med GPS-klockmaskinvara installerad. Varje värd kör tre domänanslutna Windows-gäster, som är ordnade enligt följande topologi. Raderna representerar tidshierarkin och protokollet/transporten som används.

Översikt över grafiska resultat

Följande två diagram representerar tidsnoggrannheten för två specifika medlemmar i en domän baserat på föregående topologi. Varje diagram visar både Windows Server 2012 R2- och 2016-resultaten överlagrade, vilket visar förbättringarna visuellt. Noggrannheten mättes inifrån gästdatorn jämfört med värdmaskinen. De grafiska data representerar en delmängd av hela uppsättningen tester som vi utförde och visar de bästa och värsta scenarierna.

Prestanda för rotdomänens PDC

Rot-PDC synkroniseras med värden Hyper-V (med hjälp av VMIC), som är en Windows Server 2016 med GPS-maskinvara som har visat sig vara både exakt och stabil. Det här kravet är kritiskt för 1 ms noggrannhet, som visas som det skuggade området identifierat av textetiketten.

Prestanda för den underordnade domänklienten

Den underordnade domänklienten är kopplad till en underordnad domän-PDC som kommunicerar med rot-PDC. Dess tid ligger också inom kravet på 1 ms.

Långdistanstest

I följande diagram jämförs ett virtuellt nätverkshopp med sex fysiska nätverkshopp med Windows Server 2016. Två diagram överlagras på varandra med transparens för att visa överlappande data. Att öka nätverkshopp innebär högre svarstid och större tidsavvikelser. Diagrammet är förstorat, så gränserna på 1 ms, som representeras av det skuggade området, är större. Som du ser är tiden fortfarande inom 1 ms med flera hopp. Den har flyttats negativt, vilket visar en nätverksasymmetri. Varje nätverk skiljer sig och mätningarna är beroende av många miljöfaktorer.

Metodtips för korrekt tidshållning

Följ dessa metodtips för korrekt tidshållning.

Stabil källklocka

En dators tid är bara lika bra som källklockan som den synkroniseras med. För att uppnå 1 ms noggrannhet behöver du GPS-maskinvara eller en tidsserver i nätverket som du refererar till som masterklocka. Att använda standardinställningen time.windows.com kanske inte ger en stabil och lokal tidskälla. När du kommer längre bort från källklockan påverkar nätverket noggrannheten. Att ha en huvudkällaklocka i varje datacenter krävs för bästa noggrannhet.

Gps-alternativ för maskinvara

Olika maskinvarulösningar kan erbjuda korrekt tid. I allmänhet baseras lösningar idag på GPS-antenner. Radio- och fjärrmodemlösningar använder dedikerade linjer. De ansluter till nätverket som en apparat eller ansluter till en dator, till exempel Windows via en PCIe- eller USB-enhet. Olika alternativ ger olika noggrannhetsnivåer, och som alltid beror resultaten på din miljö. Variabler som påverkar noggrannheten är GPS-tillgänglighet, nätverksstabilitet och belastning samt datormaskinvara. Dessa faktorer är alla viktiga när du väljer en källklocka, vilket är ett krav för stabil och korrekt tid.

Domän och synkroniseringstid

Domänmedlemmar använder domänhierarkin för att avgöra vilken dator de använder som källa för att synkronisera tid. Varje domänmedlem hittar en annan dator att synkronisera med och sparar den som sin klockkälla. Varje typ av domänmedlem följer en annan uppsättning regler för att hitta en klockkälla för tidssynkronisering. PDC i skogsroten är standardklockkällan för alla domäner. Här visas olika roller och beskrivningar på hög nivå för hur de hittar en källa:

• Domänkontrollant med PDC-roll: Den här datorn är den auktoritativa tidskällan för en domän. Den har den mest exakta tid som är tillgänglig i domänen. Den måste synkroniseras med en domänkontrollant i den överordnade domänen, förutom i fall där GTIMESERV-rollen är aktiverad.
• Alla andra domänkontrollanter: Den här datorn fungerar som en tidskälla för klienter och medlemsservrar i domänen. En domänkontrollant kan synkronisera med PDC för sin egen domän eller valfri domänkontrollant i sin överordnade domän.
• Klienter/medlemsservrar: Den här datorn kan synkroniseras med valfri domänkontrollant eller PDC för sin egen domän eller en domänkontrollant eller PDC i den överordnade domänen.

Baserat på tillgängliga kandidater används ett bedömningssystem för att hitta den bästa tidskällan. Det här systemet tar hänsyn till tidskällans tillförlitlighet och dess relativa plats. Den här kontrollen sker en gång när tjänsten startas. Om du behöver ha bättre kontroll över hur tiden synkroniseras kan du lägga till lämpliga tidsservrar på specifika platser eller lägga till redundans. Mer information finns i avsnittet Ange en lokal tjänst för tillförlitlig tid med hjälp av GTIMESERV.

Miljöer med blandade operativsystem (Windows Server 2012 R2 och Windows Server 2008 R2)

Även om en ren Windows Server 2016-domänmiljö krävs för bästa noggrannhet, finns det fortfarande fördelar i en blandad miljö. Att distribuera Windows Server 2016 Hyper-V i en Windows Server 2012-domän gynnar gästerna på grund av de förbättringar vi nämnde, men bara om gästerna också finns på Windows Server 2016. En Windows Server 2016 PDC kan leverera mer exakt tid på grund av de förbättrade algoritmerna, så det är en stabilare källa. Eftersom det kanske inte är ett alternativ att ersätta din PDC kan du i stället lägga till en Windows Server 2016 DC med GTIMESERV-rolluppsättningen, vilket skulle vara en uppgradering i noggrannhet för din domän. En Windows Server 2016 DC kan ge bättre tid till underordnade tidsklienter, men det är bara lika bra som NTP-källtiden.

Som sagt ändrades klocksöknings- och uppdateringsfrekvenserna med Windows Server 2016. Dessa frekvenser kan ändras manuellt till dina domänkontrollanter på nednivå eller tillämpas via grupprincip. Vi har inte testat dessa konfigurationer, men de bör fungera bra i Windows Server 2008 R2 och Windows Server 2012 R2 och ge vissa fördelar.

Versioner före Windows Server 2016 hade flera problem med korrekt tidsmätning. Systemtiden började glida omedelbart efter att en justering gjordes. På grund av det här problemet leder ofta hämtning av tidsexempel från en korrekt NTP-källa och konditionering av den lokala klockan med data till mindre drift i systemklockorna under intrasamplingsperioden. Resultatet är bättre tidsbehållning på operativsystemversioner på nednivå. Den bästa observerade noggrannheten var cirka 5 ms när en Windows Server 2012 R2 NTP-klient, konfigurerad med inställningarna för hög noggrannhet, synkroniserade sin tid från en korrekt Windows Server 2016 NTP-server.

I vissa scenarier med gäst-DCs kan Hyper-V TimeSync-exempel störa synkroniseringen av domäntid. Det här problemet bör inte längre finnas för Windows Server 2016-gäster som körs på Windows Server 2016 Hyper-V värdar.

Om du vill inaktivera tjänsten Hyper-V TimeSync från att tillhandahålla exempel till W32Time anger du följande gästregisternyckel:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider "Enabled"=dword:00000000

Tillåt att Linux använder Hyper-V värdtid

För Linux-gäster som körs i Hyper-V är klienter vanligtvis konfigurerade att använda NTP-daemon för tidssynkronisering mot NTP-servrar. Om Linux-distributionen stöder TimeSync version 4-protokollet och Linux-gästen har timesync-integreringstjänsten aktiverad synkroniseras den mot värdtiden. Det här scenariot kan leda till inkonsekvent tidshållning om båda metoderna är aktiverade.

Om du vill synkronisera exklusivt mot värdtiden rekommenderar vi att du inaktiverar NTP-tidssynkronisering med någon av två metoder:

• Inaktivera alla NTP-servrar i ntp.conf filen.
• Inaktivera NTP-daemonen.

I den här konfigurationen är parametern Tidsserver den här värden. Avsökningsfrekvensen är 5 sekunder och klockuppdateringsfrekvensen är också 5 sekunder.

Om du vill synkronisera exklusivt via NTP rekommenderar vi att du inaktiverar TimeSync-integreringstjänsten i gästen.

Ange en lokal tjänst för tillförlitlig tid med hjälp av GTIMESERV

Du kan ange en eller flera domänkontrollanter som korrekta källklockor med hjälp av flaggan Good Time Server GTIMESERV. Till exempel kan specifika DC:er som är utrustade med GPS-maskinvara flaggas som GTIMESERV. Den här flaggan ser till att domänen refererar till en klocka baserat på GPS-maskinvaran.

TIMESERV är en annan relaterad domäntjänstflagga som anger om en dator för närvarande är behörig, vilket kan ändras om en domänkontrollant tappar anslutningen. En domänkontrollant i det här tillståndet returnerar Unknown Stratum vid frågor via NTP. Efter att ha försökt flera gånger loggar DC systemhändelsen med ID Time-Service, händelse 36.

Om du vill konfigurera en domänkontrollant som GTIMESERV konfigurerar du den manuellt med hjälp av följande kommando. I det här fallet använder domänkontrollanten en annan dator som huvudklocka. Den här datorn kan vara en apparat eller dedikerad dator.

w32tm /config /manualpeerlist:"master_clock1,0x8 master_clock2,0x8" /syncfromflags:manual /reliable:yes /update

Om domänkontrollanten har GPS-maskinvaran installerad använder du följande steg för att inaktivera NTP-klienten och aktivera NTP-servern.

Börja med att inaktivera NTP-klienten och aktivera NTP-servern med hjälp av dessa ändringar av registernyckeln:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\NtpClient /v Enabled /t REG_DWORD /d 0 /f

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\NtpServer /v Enabled /t REG_DWORD /d 1 /f

Starta sedan om Windows-tidstjänsten:

net stop w32time && net start w32time

Slutligen anger du att den här datorn har en tillförlitlig tidskälla:

w32tm /config /reliable:yes /update

Kontrollera att ändringarna har gjorts korrekt genom att köra följande kommandon, som påverkar de resultat som visas här:

w32tm /query /configuration

Value|Expected Setting|
----- | ----- |
AnnounceFlags| 5 (Local)|
NtpServer |(Local)|
DllName |C:\WINDOWS\SYSTEM32\w32time.DLL (Local)|
Enabled |1 (Local)|
NtpClient| (Local)|

w32tm /query /status /verbose

Value| Expected Setting|
----- | ----- |
Stratum| 1 (primary reference - syncd by radio clock)|
ReferenceId| 0x4C4F434C (source name: "LOCAL")|
Source| Local CMOS Clock|
Phase Offset| 0.0000000s|
Server Role| 576 (Reliable Time Service)|

Windows Server 2016 på virtuella plattformar från tredje part

När Windows virtualiseras ansvarar Hypervisor som standard för att tillhandahålla tid. Men domänanslutna medlemmar måste synkroniseras med domänkontrollanten för att Active Directory ska fungera korrekt. Det är bäst att inaktivera all tidsvirtualisering mellan gästanvändaren och värden för virtuella plattformar från tredje part.

Identifiera hierarkin

Eftersom tidskedjan till huvudkällklockan är dynamisk och förhandlas i en domän, måste du kontrollera statusen för en viss dator för att förstå dess tidskälla och hur den kopplas till huvudkällklockan. Den här informationen kan hjälpa dig att diagnostisera problem med tidssynkronisering.

Om du vill felsöka en specifik klient är det första steget att förstå dess tidskälla med hjälp av det här w32tm kommandot:

w32tm /query /status

Resultatet visar bland annat källan. Källan anger vem du synkroniserar tid med i domänen. Det är det första steget i datorns tidshierarki. Använd sedan källposten från föregående kommando och använd parametern /stripchart för att hitta nästa tidskälla i kedjan.

w32tm /stripchart /computer:MySourceEntry /packetinfo /samples:1

Följande kommando listar varje domänkontrollant som kan hittas i den angivna domänen och skriver ut ett resultat som gör det möjligt för dig att fastställa varje partner. Det här kommandot innehåller datorer som har konfigurerats manuellt.

w32tm /monitor /domain:my_domain

Med hjälp av listan kan du spåra resultatet via domänen och förstå hierarkin och tidsförskjutningen i varje steg. Genom att hitta den punkt där tidsförskjutningen blir betydligt sämre kan du hitta roten för den felaktiga tiden. Därifrån kan du försöka förstå varför den tiden är felaktig genom att aktivera w32tm loggning.

Använd Grupprincip

Du kan använda grupprincip för att utföra striktare noggrannhet genom att till exempel tilldela klienter att använda specifika NTP-servrar eller för att styra hur operativsystem på nednivå konfigureras när de virtualiseras. Här är en lista över möjliga scenarier och relevanta grupprincipinställningar:

Virtualiserade domäner: Om du vill styra virtualiserade domänkontrollanter i Windows Server 2012 R2 så att de synkroniserar tid med sin domän i stället för med Hyper-V värd kan du inaktivera den här registerposten. För PDC ska du inte inaktivera posten eftersom Hyper-V-host levererar den mest stabila tidskällan. Registerposten kräver att du startar om W32Time när den har ändrats.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider] "Enabled"=dword:00000000

Noggrannhetskänsliga belastningar: För tidsnoggrannhetskänsliga arbetsbelastningar kan du konfigurera grupper av datorer för att ange NTP-servrarna och eventuella relaterade tidsinställningar, till exempel avsöknings- och klockuppdateringsfrekvens. Den här uppgiften hanteras normalt av domänen, men för mer kontroll kan du rikta specifika datorer så att de pekar direkt på huvudklockan.

Fjärrnoggrannhetskänsliga inläsningar: För system i grendomäner, till exempel Retail och Payment Credit Industry (PCI), använder Windows den aktuella platsinformationen och DC-positioneraren för att hitta en lokal domänkontrollant, såvida det inte finns en manuell NTP-tidskälla konfigurerad. Den här miljön kräver en noggrannhet på 1 sekund, vilket innebär snabbare konvergens till korrekt tid. Med det här alternativet kan W32Time flytta klockan bakåt. Om det här beteendet är acceptabelt och uppfyller dina krav kan du skapa följande princip. Precis som med alla miljöer bör du testa och fastställa en baslinje för nätverket.

Inställningen MaxAllowedPhaseOffset finns under System\Windows Time Service med hjälp av inställningarna för global konfiguration .

Överväganden för Azure och Windows IaaS

Här följer några saker att tänka på för Azure- och Windows-infrastruktur som en tjänst (IaaS).

Virtuell Azure-dator: Active Directory Domain Services

Om den virtuella Azure-dator som kör Active Directory Domain Services ingår i en befintlig lokal Active Directory-skog bör TimeSync (VMIC) inaktiveras. Med den här åtgärden kan alla domänkontrollanter i skogen, både fysiska och virtuella, använda en enda tidssynkroniseringshierarki. Mer information finns i Köra domänkontrollanter i Hyper-V.

Virtuell Azure-dator: Domänansluten dator

Om du driver en dator som är domänansluten till en befintlig Active Directory-skog, både virtuell eller fysisk, är bästa praxis att inaktivera TimeSync för gästen och se till att W32Time är konfigurerat för att synkronisera med dess domänkontrollant (DC) genom att konfigurera tid för Type=NTP5.

Virtuell Azure-dator: Fristående arbetsgruppsdator

Om den virtuella Azure-datorn inte är ansluten till en domän och den inte är en domänkontrollant rekommenderar vi att du behåller standardtidskonfigurationen och att den virtuella datorn synkroniseras med värden.

Windows-programmet kräver korrekt tid

Här följer några åtgärder som du kan vidta om ditt Windows-program kräver korrekt tid.

API för tidsstämpel

Program som kräver den största noggrannheten i förhållande till UTC, och inte tidens gång, bör använda Api:et GetSystemTimePreciseAsFileTime. Med det här API:et ser du till att programmet får systemtid, vilket villkoras av Windows-tidstjänsten.

UDP-prestanda

Om du har ett program som använder UDP-kommunikation för transaktioner och det är viktigt att minimera svarstiden finns det några relaterade registerposter som du kan använda för att konfigurera ett portintervall som ska undantas från portbasfiltreringsmotorn. Den här åtgärden förbättrar både svarstiden och ökar dataflödet. Ändringar i registret bör dock begränsas till erfarna administratörer. Den här lösningen utesluter portar från att skyddas av brandväggen. Mer information finns i följande referens.

För Windows Server 2012 och Windows Server 2008 måste du installera en snabbkorrigering först. Mer information finns i Datagram-förlust när du kör ett mottagarprogram för multicast i Windows 8 och Windows Server 2012.

Uppdatera nätverksdrivrutiner

Vissa nätverksleverantörer har drivrutinsuppdateringar som förbättrar prestanda i förhållande till drivrutinsfördröjning och buffring av UDP-paket. Kontakta nätverksleverantören för att se om det finns uppdateringar som hjälper dig med UDP-dataflödet.

Loggning i granskningssyfte

Om du vill följa reglerna för tidsspårning kan du arkivera w32tm loggar, händelseloggar och information om prestandaövervakaren manuellt. Senare kan den arkiverade informationen användas för att intyga efterlevnad vid en viss tidpunkt tidigare. Följande faktorer används för att indikera noggrannheten:

1. Klocknoggrannhet med hjälp av Prestandaövervakningsräknaren för Beräknad Tidsförskjutning. Den här räknaren visar klockan inom önskad noggrannhet.
2. Klockkälla letar efter Peer Response from i w32tm loggarna. Följande meddelandetext är IP-adressen eller VMIC, som beskriver tidskällan och nästa i kedjan med referensklockor som ska verifieras.
3. Status för klocktillstånd genom att använda loggarna w32tm för att verifiera att ClockDispl Discipline: \*SKEW\*TIME\* inträffar. Den här statusen anger att w32tm är aktiv vid den tidpunkten.

Händelseloggning

För att få hela artikeln behöver du även information om händelseloggen. Genom att samla in systemhändelseloggen och filtrera på Time-Server, Microsoft-Windows-Kernel-Boot och Microsoft-Windows-Kernel-General kanske du kan identifiera om andra påverkan har ändrat tiden, till exempel tredje part. Dessa loggar kan vara nödvändiga för att utesluta externa störningar. Grupprincip kan påverka vilka händelseloggar som skrivs till loggen. Mer information finns i föregående avsnitt Använda grupprincip.

W32Time-felsökningslogg

För att aktivera w32tm i granskningssyfte aktiverar följande kommando loggning som visar de periodiska uppdateringarna av klockan och anger källklockan. Starta om tjänsten för att aktivera den nya loggningen.

Mer information finns i Aktivera felsökningsloggning i Windows-tidstjänsten.

w32tm /debug /enable /file:C:\Windows\Temp\w32time-test.log /size:10000000 /entries:0-73,103,107,110

Performance Monitor

Windows Server 2016 Windows Time-tjänsten exponerar prestandaräknare som kan användas för att samla in loggning för granskning. Dessa räknare kan loggas lokalt eller via fjärranslutning. Du kan registrera räknarna Datortidsförskjutning och Fördröjning av tur och retur . Precis som med alla prestandaräknare kan du fjärrövervaka dem och skapa aviseringar med hjälp av System Center Operations Manager. Du kan till exempel använda en avisering för att varna dig när tidsförskjutningen avviker från önskad noggrannhet. Mer information finns i System Center-hanteringspaketet.

Exempel på Windows-spårning

Från w32tm loggfiler vill du verifiera två typer av information. Den första är en indikation på att loggfilen för närvarande är en villkorsklocka. Den här indikationen bevisar att klockan villkorades av Windows Time-tjänsten vid den omtvistade tidpunkten.

 151802 20:18:32.9821765s - ClockDispln Discipline: *SKEW*TIME* - PhCRR:223 CR:156250 UI:100 phcT:65 KPhO:14307
 151802 20:18:33.9898460s - ClockDispln Discipline: *SKEW*TIME* - PhCRR:1 CR:156250 UI:100 phcT:64 KPhO:41
 151802 20:18:44.1090410s - ClockDispln Discipline: *SKEW*TIME* - PhCRR:1 CR:156250 UI:100 phcT:65 KPhO:38

Huvudpunkten är att du ser meddelanden som är prefixet med ClockDispln Discipline, vilket är ett bevis på att W32Time interagerar med systemklockan.

Därefter måste du hitta den sista rapporten i loggen före den omtvistade tiden som rapporterar källdatorn, som för närvarande används som referensklocka. Den här informationen kan vara en IP-adress, ett datornamn eller VMIC-leverantören, vilket indikerar att den synkroniseras med värdenheten för Hyper-V. I följande exempel finns en IPv4-adress på 10.197.216.105:

151802 20:18:54.6531515s - Response from peer 10.197.216.105,0x8 (ntp.m|0x8|0.0.0.0:123->10.197.216.105:123), ofs: +00.0012218s

Nu när du har verifierat det första systemet i referenstidskedjan måste du undersöka loggfilen på referenstidskällan och upprepa samma steg. Den här processen fortsätter tills du kommer till en fysisk klocka, till exempel GPS, eller en känd tidskälla, som NIST. Om referensklockan är GPS-maskinvara kan loggar från den tillverkade också krävas.

Nätverksöverväganden

NTP-protokollalgoritmerna är beroende av nätverkets symmetri. När du ökar antalet nätverkshopp ökar sannolikheten för asymmetri. Därför är det svårt att förutsäga vilka typer av noggrannheter du ser i dina specifika miljöer.

Prestandaövervakaren och de nya Windows Time-räknarna i Windows Server 2016 kan användas för att utvärdera miljöns noggrannhet och skapa baslinjer. Du kan också utföra felsökning för att fastställa den aktuella förskjutningen för vilken maskin som helst i ditt nätverk.

Det finns två allmänna standarder för korrekt tid över nätverket:

• Precision Time Protocol – IEEE 1588(PTP): PTP har strängare krav på nätverksinfrastruktur men kan ofta ge submicrosecond noggrannhet.
• Network Time Protocol – RFC 1305(NTP): NTP fungerar på en större mängd olika nätverk och miljöer, vilket gör det enklare att hantera.

Windows stöder enkel NTP (RFC2030) som standard för icke-domän-anslutna datorer. För domänanslutna datorer använder vi en säker NTP med namnet MS-SNTP, som använder domänförhandlade hemligheter som ger en hanteringsfördel jämfört med autentiserad NTP som beskrivs i RFC1305 och RFC5905.

Både domän- och icke-domänanslutna protokoll kräver UDP-port 123. Mer information om metodtips för NTP finns i Network Time Protocol Best Current Practices IETF Draft.

Tillförlitlig maskinvaruklocka (RTC)

Windows justerar inte tiden, såvida inte vissa gränser överskrids, utan istället korrigerar klockan. Det innebär att w32tm justerar klockans frekvens med ett regelbundet intervall med hjälp av inställningen Frekvens för klockuppdatering , som standard är en gång i sekunden med Windows Server 2016. Om klockan ligger bakom påskyndas frekvensen. Om det ligger före, saktar det ner frekvensen. Men under tiden mellan klockfrekvensjusteringar har maskinvaruklockan kontroll. Om det uppstår ett problem med den inbyggda programvaran eller maskinvaruklockan kan tiden på datorn bli mindre exakt.

Det här scenariot är en annan orsak till varför du behöver testa och fastställa en referensnivå i din miljö. Om prestandamätaren beräknad tidsförskjutning inte stabiliseras vid den noggrannhet du siktar på, kanske du vill kontrollera att den inbyggda programvaran är uppdaterad. Som ett annat test kan du se om duplicerad maskinvara återskapar samma problem.

Felsöka tidsnoggrannhet och NTP

Du kan använda avsnittet Identifiera hierarkin för att förstå källan till den felaktiga tiden. Om du tittar på tidsförskjutningen letar du reda på den punkt i hierarkin där tiden avviker mest från dess NTP-källa. När du förstår hierarkin vill du försöka förstå varför den aktuella tidskällan inte får rätt tid.

Genom att fokusera på systemet med avvikande tid kan du använda följande verktyg för att samla in mer information som hjälper dig att fastställa problemet och hitta en lösning. Referensen UpstreamClockSource är den klocka som upptäcktes med hjälp av w32tm /config /status:

• Systemhändelseloggar
• Aktivera loggning med hjälp av w32tm logs - w32tm /debug /enable /file:C:\Windows\Temp\w32time-test.log /size:10000000 /entries:0-300
• w32Time-registernyckel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time
• Lokala nätverksspårningar
• Prestandaräknare (från den lokala datorn eller UpstreamClockSource)
• W32tm /stripchart /computer:UpstreamClockSource
• PING UpstreamClockSource för att förstå svarstid och antal hopp till källan
• Tracert (Spår) UpstreamClockSource

Baslineringstid

Baslinering är viktigt så att du kan förstå nätverkets prestanda och noggrannhet och sedan jämföra det med baslinjen i framtiden när problem uppstår. Du vill baslinje den ursprungliga PDC:n eller datorer som har markerats med GTIMESRV. Vi rekommenderar också att du har en baslinje för PDC i varje skog. Välj slutligen alla kritiska domänkontrollanter eller datorer som har intressanta egenskaper, t.ex. avstånd eller hög belastning, och baslinje för dessa.

Det är också användbart för baslinje för Windows Server 2016 jämfört med 2012 R2. Du har w32tm /stripchart dock bara som ett verktyg som du kan använda för att jämföra eftersom Windows Server 2012 R2 inte har prestandaräknare. Du bör välja två datorer med samma egenskaper eller uppgradera en dator och jämföra resultatet efter uppdateringen. Tillägget om Windows tidsmätningar innehåller mer information om hur du utför detaljerade mätningar mellan 2016 och 2012.

Genom att använda alla W32Time-prestandaräknare samlar du in data i minst en vecka. Denna data säkerställer att du har tillräckligt med referens för att ta hänsyn till variationer i nätverket över tid och tillräckligt med mätning för att säkerställa att din tidsnoggrannhet är stabil.

NTP-serverredundans

För manuell NTP-serverkonfiguration som används med icke-domänanslutna datorer eller PDC är det ett bra redundansmått att ha fler än en server i händelse av tillgänglighet. Det kan också ge bättre noggrannhet, förutsatt att alla källor är korrekta och stabila. Men om topologin inte är väl utformad eller om tidskällorna inte är stabila kan den resulterande noggrannheten vara värre, så försiktighet rekommenderas. Gränsen för tidsservrar som stöds som W32Time kan referera till manuellt är 10.

Skottsekunder

Jordens rotationsperiod varierar över tid på grund av klimatiska och geologiska händelser. Vanligtvis är variationen ungefär en sekund vartannat år. När variationen från atomisk tid växer sig för stor infogas en korrigering av en sekund (upp eller ned), vilket kallas för ett steg tvåa. Den här insättningen görs på ett sådant sätt att skillnaden aldrig överskrider 0,9 sekunder. Denna korrigering tillkännages sex månader före den faktiska korrigeringen. Före Windows Server 2016 kände Microsoft Time Service inte till skottsekunder, men förlitade sig på den externa tidstjänsten för att ta hand om det här problemet. Med den ökade tidsnoggrannheten i Windows Server 2016 arbetar Microsoft med en bättre lösning för skottsekundsproblemet.

Säker tidssådd

W32Time i Server 2016 innehåller funktionen För säker tidssådd. Den här funktionen avgör den ungefärliga aktuella tiden från utgående SSL-anslutningar. Det här tidsvärdet används för att övervaka den lokala systemklockan och korrigera eventuella bruttofel. Du kan läsa mer om funktionen i det här blogginlägget. I miljöer med tillförlitliga tidskällor och väl övervakade datorer som övervakar tidsförskjutningar kan du välja att inte använda Secure Time Seeding-funktionen och i stället förlita dig på din befintliga infrastruktur.

Så här inaktiverar du funktionen:

1. Använd grupprincip för att hantera SecureTimeSeeding. Se avsnittet som refererar till inställningen UtilizeSslTimeData: Learn: Policy CSP – ADMX_W32Time.

2. Du kan också ange registervärdet manuellt. Ange registerkonfigurationsvärdet UtilizeSSLTimeData till 0 på en specifik dator:

   reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config /v UtilizeSslTimeData /t REG_DWORD /d 0 /f
   

3. Om du inte kan starta om datorn omedelbart kan du meddela W32Time om konfigurationsuppdateringen. Det här meddelandet stoppar tidsövervakning och tillämpning baserat på tidsdata som samlas in från SSL-anslutningar.

   W32tm.exe /config /update
   

4. Omstart av datorn gör att inställningen börjar gälla omedelbart och gör också att den slutar samla in tidsdata från SSL-anslutningar. Den senare delen har en liten omkostnad och bör inte vara ett prestandaproblem.

5. Om du vill använda den här inställningen i en hel domän anger du UtilizeSSLTimeData värdet i grupprincipinställningen W32Time till 0 och publicerar inställningen. När inställningen hämtas av en grupprincipklient meddelas W32Time och den stoppar tidsövervakning och tillämpning med hjälp av SSL-tidsdata. SSL-tidsdatainsamlingen stoppas när varje dator startas om. Om din domän har bärbara smala bärbara datorer/surfplattor och andra enheter kanske du vill undanta sådana datorer från den här principändringen. Dessa enheter står så småningom inför batteritorsk och behöver funktionen Secure Time Seeding för att starta om sitt tidssystem.