NIST-tijdmeting wijkt 4 microsecondes af door stroomuitval in Colorado

Stroomuitval door zware wind in de Amerikaanse staat Colorado veroorzaakte een afwijking in de tijdmeting van de NIST Internet Time Service in Boulder. De meting met een atoomklok lag korte tijd stil, wat telecommunicatie- en internetdiensten heeft kunnen raken.

NIST verklaart dat de tijdmeting door de stroomuitval een afwijking van 4 microsecondes had, meldt CBS News. Voor de meeste gebruikers van de NIST-tijdmeting had dit volgens een woordvoerster geen gevolgen. Voor gebruikers in sectoren met extreem hoge tijdsgevoeligheid, zoals telecommunicatie, ruimtevaart en bepaalde laboratoria, zou zo'n afwijking wel impact kunnen hebben.

De woordvoerster van NIST stelt dat voor zulke gebruikers altijd een tijdmeting op andere locaties beschikbaar is. "We hebben zulke high-end gebruikers op de hoogte gesteld van een mogelijke stroomuitval, zodat zij voorbereid konden zijn om die netwerken te gebruiken als voorzorgsmaatregel."

De stroomuitval was een bewuste handeling van nutsbedrijf Xcel Energy dat de elektriciteitsvoorziening uitschakelde om schade en brandgevaar te voorkomen. Dit onderbrak ook de stroom voor de servers die NIST gebruikt om de tijdmeting van de atoomklok te registreren en door te geven. Het overschakelen naar een back-upgenerator kostte even, waardoor de zeer nauwkeurige tijdmeting kort werd verstoord.

Reacties (89)

[T-men]

"Ow... We hebben 4 microseconden te weinig. Gelukkig werken we met computers. Dat zijn krachtige rekenapparaten. Effe +4us en opgelost."

Maar dat zal te simpel zijn (we missen nu een aantal microseconden). Maar ook dat is gek omdat schrikkelseconden geen probleem lijken, laat staan de situatie waarbij de relativiteitstheorie theorie voorbij komt als de maan hoog aan de hemel staat e.d

[Mijzelf]

Schrikkelseconden zijn wel een probleem. In 2022 is op de General Conference on Weights and Measures besloten dat er tussen 2035 en 2135 géén schrikkelseconden zullen worden toegepast omdat het teveel problemen oplevert.

Link

[Reactie gewijzigd door Mijzelf op 21 december 2025 13:25]

[kiang]

Nog even aanvullen: er is beslist om het honderd jaar niet te doen, en daarna.... Dat zien we dan wel weer, dat is een probleem voor de mensen van de toekomst letterlijk het probleem vooruit schuiven.

Niet echt een enorm probleem als je het mij vraagt, maar wel grappig, eigenlijk is het gewoon een soort ragequit van de huidge specialisten

Voor wie het interesseert en zich afvraagt waarom schrikkelseconden zo een probleem zijn terwijl we ook schrikkeljaren hebben sinds de tijd van Caesar (en daarna verbeterd door paus Gregorius in 1582): het verschil is dat schrikkeljaren gebaseerd zijn op de rotatie om de zon, die heel erg stabiel en dus voorspelbaar is, en de schrikkelseconde is gebaseerd op de rotatie van de aarde om zijn eigen as, een rotatie die veel minder stabiel is.

Zo had bijvoorbeeld de bouw van de Chinese three Gorges dam een merkbaar effect op de rotatie van aarde om eigen as.

Wie wil weten hoe schrikkelseconden nu werken: de schrikkelseconde is ingevoerd om onze klokken in sync te houden met de stand van de zon. Als mensen geloven we namelijk meerdere dingen die allemaal ongeveer waar zijn, maar niet tegelijk helemaal waar kunnen zijn:

• Een seconde duurt altijd even lang
• Een dag heeft altijd even veel seconden

Aangezien de rotatie van de aarde varieert, kunnen beiden niet waar zijn. Als je een voorkeur tussen deze twee hebt, kan je kiezen:

• De klok TAI (internationale atoomtijd) heeft seconden die altijd even lang zijn, dit is de gemiddelde atoomtijd van een set atoomklokken die verspreid over de aarde staan. Deze maor goed op de Unix epoch btw. Deze klok heeft echter geen directe alledaags praktische betekenis: het zegt in principe niets over of het ergens ochtend of avond is.
• De klok UT1 (universele tijd) is een klok die gebaseerd is op de rotatie van de aarde en onze oriëntatie tegenover de zon (oftewel: de zon staat om 12u exact op zijn hoogste punt, en de tijd tussen 2 zeniths is altijd exact 24x3600 seconden). Als de aarde trager draait duren secondea op die klokken wat langer, als de aarde sneller draait gaat de klok wat sneller.

Dit zijn dus beide heel 'principiële' klokken die een bepaald principe (secondes duren even lang versus elke dag heeft even veel seconden) strikt toepassen, maar ze lopen niet gelijk: inmiddels is er een verschil van een 30-tal seconden opgebouwd sinds de jaren 70 (edit: kijk maar: TAI vs UTC, waar ik het zo over heb)

In het alledaagse leven willen we natuurlijk beiden, en daar hebben we een mooi compromis voor ontwikkeld: UTC. Dit is zo'n ultiem compromis dat zelfs de naam een compromis is: de Fransen en de Engelsen werden het niet eens of het nu UCT (universal coordinated time) of TUC (temps universal coordiné) moest worden, en dus werd het betekenisloze UTC gekozen zodat niemand 'won' Je zou kunnen stellen dat UTC staat voor "Ultimate Time Compromise".

UTC introduceert schrikkelseconden: men begint origineel met TAI als basis, en men kijkt naar UT1 om een offset tegenover TAI bij te houden. Wanneer het verschil tussen beiden groter wordt dan 0,5 seconden, dan wordt de eerstvolgende 30 juni of de eerstvolgende 31 december een seconde overgeslagen of toegevoegd om middernacht (tot nu toe is er nog nooit een seconde overgeslagen). Op die manier duren dagen bijna altijd even lang. Leve het compromis!

Echter. Deze onvoorspelbare schrikkelseconden hebben geen patroon, en dus moet men, telkens de nood aan een schrikkelseconde wordt waargenomen, een update worden gepusht naar alle systemen over de hele wereld. Elk OS en stuk software dat met tijdsstempels omgaat heeft ergens een lijstje met daarin de bekende schrikkelseconden en die moet toegepast worden . Dit is echt vreselijk gepriegel, en daarom is er nu dus beslist om hier binnenkort mee te stoppen voor 100 jaar in de hoop dat we iets makkelijkere kunnen bedenken.

[Reactie gewijzigd door kiang op 22 december 2025 00:24]

[mrottjers]

Verbazend dat er geen reacties komen op 31 juni terwijl er een hele discussie is over 0.004 ms. Wel heldere uiteenzetting van schrikkelseconden waarvoor dank!

[kiang]

Foutje Dankje om erop te wijzen!

[arjankoole]

is dat niet mee omdat over 100 jaar het hele speelveld er zo anders uitziet, dat het minder of geen problemen zal gaan opleveren?

100 jaar is best lang, geen korte termijn oplossing en vooruitschuiven. Over 90 jaar evalueren of het nog nodig is, of dat we schrikkelseconden kunnen doen.

[kiang]

Nou ja, dat hopen we inderdaad, maar je kan het niet weten.

[intrixius]

ik herinner me nog, zo'n 20 jaar geleden, toen ik als technieker voor communicatieapparatuur op de luchthaven van brussel werkte, dat men de paar minuten rond middernacht waar een schrikkelseconde werd toegevoegd (58, 59, 60, 00, 01... ipv 58, 59, 00, 01,...) alle apparatuur waarvan men vermoedde dat die niet konden omgaan met die extra "60" als seconde gewoon uitschakelde... problem solved :-)

[m_snel]

In het begin van de Patriot zat er een afrondingsfout in de software, en dat kan bij het berekenen van de baan van de raket een groot verschil maken.

[tedades]

Het probleem dat ik zie is dat ze NTP juist gebruiken om die afwijking van hun interne klok te bepalen. Veel systemen hebben dus al een accurate klok. Zodra NTP zelf gaat afwijken gaan alle getrainde klokjes dus denken dat ze fout zitten en gaan zichzelf corrigeren.

[The Third Man]

NTP is toch slechts het protocol, het gaat om de uiteindelijke bron die wel of niet dat risico heeft. Als dat een andere atoomklok is dan kan het systeem zichzelf nooit zo’n feedback loop geven als jij nu voorstelt.

[tedades]

Mijn aanname is inderdaad dat je bron van tijd zeer accuraat is en je NTP gebruikt om minder accurate klokken te kalibreren. Door die kalibratie zullen ze beter presteren. Zodra je bron een foutieve tijd aan geeft zal de kalibratie van de andere klokken dus verstoord worden.

Je kunt NTP ook gebruiken om eenmalige de tijd op je PC goed te zetten maar daar zal de impact klein zijn mocht je een paar millisecondes missen.

[MSalters]

"Kalibreren" heeft een heel precieze betekenis, en NTP is daar niet voor. NTP is voor synchronisatie met een master clock (atoomklok of proxy daarvan). Atoomklokken kun je met elkaar kalibreren maar dat werkt anders.

[tedades]

Ik heb "discipline" vertaald naar kalibreren omdat ik de Nederlandse term hiervoor niet ken.

De documentatie van NTP over dit concept: https://www.ntp.org/documentation/4.2.8-series/discipline/

[necessaryevil]

Even een correctie doen door in de computer plus 4 µs te doen zal niet werken omdat je dit niet nauwkeurig kan doen. Als dat wel kon, had die server die atoomklok niet nodig gehad. Je kunt je überhaupt al af hoe nauwkeurig die 4µs. Dat zal een soort schatting zijn.

[jongetje]

Als je al weet dat er een stroom onderbreking komt, dan zorg je toch dat je (ruim) daarvoor op noodstroom draait. Dan wacht je toch niet tot het moment dat het uit wordt geschakeld met als gevolg dat het overschakelen moeizaam gaat...

[Marcva]

Er ging iets mis, maar er is waarschijnlijk niets verloren:

However, we now have strong evidence one of the crucial generators has failed. In the downstream path is the primary signaldistribution chain, including to the Boulder Internet Time Service. Another
campus building houses additional clocks backed up by a different power
generator; if these survive it will allow us to re-align the primary time
scale when site stability returns without making use of external clocks or
reference signals.

[wildhagen]

Als je al weet dat er een stroom onderbreking komt, dan zorg je toch dat je (ruim) daarvoor op noodstroom draait.

Dit was dus geen geplande outage in de zin van gepland onderhoud wat vooraf aangekondigd is oid.

Zie het bericht:

Due to prolonged high wind gusts there have been a combination of utility
power line damage and preemptive utility shutdowns (in the interest of
wildfire prevention) in the Boulder, CO area.

Door noodweer (wind/storm) is er dus schade ontstaan, en daardoor is er, om verdere schade te voorkomen én om bosbranden te voorkomen, dus een en ander uitgeschakeld.

[Frasi]

Het was wel aangekondigd (en dus gepland). Ik heb collega's in Denver en had net een Teams meeting met een van hen. Bij aanvang van de vergadering gaf hij aan dat er een storm was en bericht had gekregen dat de stroom uitgeschakeld kon gaan worden. En 10 minuten later, poef...

[CH4OS]

Het is niet dat in tien minuten tijd de noodgenerator op volle kracht draait (als het al mag draaien...) en een storing als deze kan voorkomen...

[Reactie gewijzigd door CH4OS op 21 december 2025 21:38]

[Frasi]

Wat ik bedoelde is dat hij na ongeveer 10 minuten in de vergadering ineens verdwenen was; verbinding verbroken. Dus dat was het moment dat bij hem (thuis in Denver) de stroom uitviel.

[sniker]

en wat iederen hier probeert duideljk te maken is dat een dergelijke korte lead time voor de daadwerkelijke uitval (in een schaal van minuten van te voren, ipv normaliter weken of op zijn minst de dag van te voren.) er niet veel haalbaar is wat betreft mogelijkheden om erop voor te breiden. en dat het responsepad nog steeds gelijk blijft aan onverwachte uitval.

[Reactie gewijzigd door sniker op 21 december 2025 22:45]

[Honytawk]

En wat Frasi probeert te zeggen is dat we helemaal niet weten hoe lang ervoor dat ze zijn geinformeerd.
Die 10 minuten is enkel wanneer die persoon Frasi informeerde.

[William_H]

Wat ik dan niet snap is dat deze locaties geen noodbatterijen hebben gehad. Want die kunnen, of hadden in ieder geval, dat opvangen. Er ook nog vanuitgaande dat er meerdere servers in een rack hangen die weer aan verschillende fases en voedingen hangen.

[CH4OS]

Dat snap ik en voordat hij het jou vertelde, zal er vast ook wat tijd hebben gezeten. Hoeveel dat totaal ook is, zolang dat maar minuten is of zelfs maar een paar uur, dat is nooit genoeg tijd om maatregelen te treffen om te voorkomen dat bepaalde zaken uitvallen. Ik denk dat op dergelijke momenten er ook wel andere prioriteiten zijn bijvoorbeeld. Die 4 microseconden zijn/konden gelukkig uiteindelijk ook gecorrigeerd worden immers.

[Reactie gewijzigd door CH4OS op 22 december 2025 00:57]

[R_Zwart]

En ook met een geplande outage kunnen dingen fout gaan. Het besef dat dingen fout kunnen gaan is bij veel mensen nog niet aanwezig. Waarschijnlijk omdat heel veel behoorlijk complexe zaken bijna altijd goed werken. Als je kijkt wat er allemaal gebeurt om dit simpele tekstbericht in real time te kunnen posten is het eerder bijzonder dat het bijna altijd goed gaat.

[kodak]

Alleen al door extreem weer is in Colorado ongeveer iedere 5 jaar een stroomuitval. Het weten gaat dus ook om dat gegeven. Als dienstverlening zo belangrijk is dan toont men aan daar behoorlijk rekening mee te hebben gehouden.

De uitleg is niet alleen dat de beschikbare noodstroom een probleem is maar ook het gebrek aan voorzieningen om het te kunnen controleren en bedienen, samen met een verbod op toegang mogen tot die voorzieningen. Er lijkt dus niet slechts een probleem te zijn met de noodstroom, maar ook het niet op orde hebben van de controle daarover. En dat is niet slecht toe te wijzen aan het weer. Bij extreem weer ben je al snel exteem afhankelijk dat alle noodvoorzieningen behoorlijk te bedienen zijn, zoals van afstand.

[ZinloosGeweldig]

Op basis waarvan kunnen we aannemen dat de stroom onderbreking al (ruim) van tevoren bekend was?

[jongetje]

Mijn aanname kwam door het stuk:

"De stroomuitval was een bewuste handeling van nutsbedrijf Xcel Energy dat de elektriciteitsvoorziening uitschakelde om schade en brandgevaar te voorkomen."

Ik nam aan dat ze dit ook communiceren dat ze de stroomvoorziening gaan uitschakelen.

[djwice]

Hebben ze denk ik ook gedaan alleen bij brandgevaar ga je niet wachten tot er nog meer gevaar ontstaat, dan handel je en externe communicatie is daar secondair aan lijkt me.

[ZinloosGeweldig]

Lijkt me toch raar, bij acuut gevaar eerst even een onderhoudsnotificatie uitsturen en een uurtje wachten voordat je de nodige gevaar beperkende maatregelen neemt.

[Lagonas]

Als stroom zo belangrijk voor je is dan neem je zelf maatregelen om dit te voorkomen, en je gaat er zeker niet van uit dat je stroom leverancier 100% uptime heeft, of jou ten alle tijden op tijd kan waarschuwen. Dan installeer je een bank batterijen zoals een UPS die het tijdelijk kunnen overnemen voordat je eigen noodstroom ingeschakeld kan worden.

[hasjee]

Zoals de bag guy in under siege 2 al zei. "Aannames zijn de moeder van alle fuckups."

[Chintzy]

'bewuste handeling' staat in dit geval denk ik niet gelijk aan 'geplande handeling'.

[jbhc]

Je gaat er vanuit dat dat kan. Dat is een verkeerde aanname.

[Bulls]

Lijkt me als zoiets zo belangrijk is dat ze bij voorbaat altijd via een backup accu lopen? Dus geen nood switch die inschakelt na onderbreking. Want daar zit ook vertraging in. Maar dus continu door een accu heen. Zodat je bij onderbreking er niets van merkt.

Maar goed ik heb er verder ook geen verstand van, alleen maar logisch nadenken.

[Mextreme]

Ik dacht vanochtend al... 'Wat is die bus zo laat!'

Nu weet ik het. Hartelijk dank.

[djwice]

Wellicht resulteert dat switchen 4 micro seconden verschuiving door het vliegwiel, weet ik het.

Jij?

[necessaryevil]

Als je al weet dat er een stroom onderbreking komt, dan zorg je toch dat je (ruim) daarvoor op noodstroom draait. Dan wacht je toch niet tot het moment dat het uit wordt geschakeld met als gevolg dat het overschakelen moeizaam gaat...

Je moet sowieso nadenken over de impact van overschakelen naar noodstroom, als dat problemen op levert dan is je noodstroomvoorziening ook een stuk minder nuttig.

Ik was toevallig het originele artikel aan het bekijken en las dit:

initial power loss, there was no immediate impact to the NIST atomic
time scale or distribution services because the projects are afforded
standby power generators. However, we now have strong evidence one of the
crucial generators has failed.

In andere woorden, er was meer aan de hand, ze denken dat er een generator is gesneuveld, of om een andere reden niet werkte.

[svenk91]

Welke afwijking wordt eigenlijk getolereerd bij zulke gevoelige casussen als je met een externe NIST server werkt over het internet? Een afwijking in de latency tussen de client en zo’n server van 1 miliseconde is al meer dan een factor 200 groter dan de storing binnen de server heeft veroorzaakt.

Als microseconden ertoe doen denk ik dat ze eerder een GNSS systeem gebruiken voor de bepaling van tijd. Omdat je ook precies de afstand tot de bron kan bepalen kan je veel accurater compenseren voor de delay tussen de verzender van de tijd (de satelliet) en de ontvanger, alleen de atmosferische toestand gooit er nog wat variabiliteit in, maar volgens mij kan je zo wel tot op 0,2 microseconde nauwkeurig de tijd bepalen met een professionele ontvanger als je continue meet.

[Illusion]

Ntp staat behoorlijk onderaan als het om nauwkeurigheid gaat. Enkele ms is daar niet raar. Dit is omdat de timestamp van het pakketje dat je vertelt hoe laat het is, pas in de softwarestack (windows/linux) gedaan wordt. Bij hoge CPU loads/interrupts kan dat dus afwijken

Als je nauwkeuriger wilt, dan gebruik je PTPv2 (IEEE1588). Daar heeft elk netwerkdevice een eigen hardware clock die het ontvangen/verzenden van pakketjes timestamped. Zelfs switches rekenen uit hoe lang een pakketje in de switch heeft rondgehangen voordat het doorgestuurd was.

PTPv2 vereist dus aangepast hardware en wordt niet over het internet gedistribueerd. Vaak plaats je dan zelf ptp-grandmasters die op ca 70nanoseconden met GNSS synchroniseren. En lokaal zowel ptp en ntp distribueren.

Voor het plannen van 5G frequentieruimte wordt dit tegenwoordig grootschalig uitgerold.

CERN heeft daarnaast nog een rol in het ontwikkelen van de opvolgers: TSN (Time Sensitive Networking) en White Rabbit.

Als je eenmaal in de timing duikt blijkt het ook echt wel een rabbit hole waar je diep in kan gaan. Neemt niet weg dat je met een raspberry pi cm4/cm5/5b en een simpele gps ontvanger al een heel behoorlijke ptp server kan maken. Zie oa jeff geeerling.

[Opperpanter2]

Network Time Protocol (NTP) works by having clients request time from servers (often connected to atomic clocks) using UDP port 123, exchanging timestamped packets, and using complex algorithms to calculate network delay (jitter) to precisely adjust the client's clock to Coordinated Universal Time (UTC), ensuring high accuracy across networks, even with variable latency. 

[MrFax]

Met andere woorden: Er wordt bij aankomst van het pakket met de tijd berekent wat de precieze tijd zou moet zijn zodra deze bij jouw computer aankomt.

Hier worden bij bijv. chronyd (wordt standaard gebruikt in RHEL en Fedora) vele verschillende tussenservers gebruikt om het nog preciezer te maken.

[Reactie gewijzigd door MrFax op 21 december 2025 11:46]

[beerse]

De chronyd en ntpd zijn redelijk vergelijkbaar. Ze gebruiken op het netwerk beide het ntp protocol.

Als je naar de implementatie kijkt blijkt dat de voorbeeld ntpd implementatie het op fysieke hardware in theorie een stuk beter kan doen dan chrony. Daarbij is beter vooral dat de klok voor de lokale processen veel stabieler is.

Chrony is vooral bedoelt voor virtuele (gast) systemen. Die hebben te maken met de scheduling van de host en kunnen minder nauwkeurig en vooral minder stabiel zijn. Chrony is er meer op gericht dat de tijden op het netwerk zo gelijk mogelijk blijven.

Als je chrony op een fysiek systeem draait (de host), dan zal je uiteindelijk geen verschil kunnen merken tussen chrony en ntp tot het systeem zwaar wordt belast en de temperatuur gaat fluctueren. Dan heb je in de regel ook andere problemen.

[CH4OS]

Hoewel UDP snel is, kent het geen foutcorrectie (zoals TCP dat wel heeft en daardoor juist trager is). Je kunt dan dus maar zo ook het pakketje verkeerd interpreteren of een foutje maken. Vervolgens ga je daarop de tijd baseren, terwijl 4 microseconden al cruciaal kunnen zijn...

[MSalters]

Nee. Het fundamentele idee van TCP is dat je de goede bytes in de goede volgorde krijgt, desnoods met veel vertraging. Dat is vaak handig.

Voor NTP is het handiger om foute pakketjes simpelweg te negeren. Daarom gebruik je geen TCP: verkeerde soort foutcorrectie. Maar je aanname dat er geen foutcorrectie is in NTP/UDP, is dus fout. Dus bij deze een foutcorrectie

[dasiro]

Daarvoor gebruiken ze het NTP-protocol niet (maar ze bieden het uiteraard ook aan), aangezien dat "amper" tot op de milliseconde juist is in ideale omstandigheden.

Voor zo'n gevoelige devices gebruiken ze IEEE 1588 PTP (Precision Time Protocol) dat tot op de microseconde nauwkeurig is, dus 1000x nauwkeuriger.

[BiLLY_daKid]

Vermogensbeheerders moeten ook in msec rekenenen, maar er zijn andere oplossingen dan 1 NTP server.

[beerse]

Welke afwijking wordt getollereerd is geheel afhankelijk van je systeem en de eisen daar aan.

Een msWindows 2016 of 2019 machine op fysieke hardware heeft van microsoft een klok synchroniseer garantie van 0.1 (1-tiende) seconde, beter kan microsoft het met msWinoows niet garanderen. Op een virtueel systeem is de garantie op zijn best een tiende slechter dus op 1 seconde. Hoe het opde huidige versies van msWindows zit weet ik niet. Wel dat het met windows nt 4.0 beter was. Voor andere mswindows systemen heb ik het niet in detail uitgezocht.

Een linux implementatie kan op fysieke hardware met het ntp protocol en de ntpd voorbeeld implementatie tot op de miliseconde (0.001 seeconde) nauwkeurig komen. Dat kan ook op systemen zoals een raspberry-pi of fysieke routers. Ook hier is een gast-systeem op zijn best een tiende slechter.

Het ntp protocol adviseert om minimaal 3 referentie klokken te gebruiken. Met gebruik van meerdere referentie klokken kan een fysiek systeem net zo nauwkeurig worden als de beste van de referentie klokken, binnen de resolutie van de klokken natuurlijk.

De snelheid en de vertraging op het netwerk heeft voor ntp minder invloed. 50 jaar geleden synchroniseerde ntp ook via seriele verbindingen en telefoon modems. En ook toen op milisecondes.

In het ntp protocol wordt gebruik gemaakt van heen en weer vertragingen: De client vraagt: Hier is het nu zo laat, hoe laat is het bij jouw? Het antwoord bevat dan deze begin tijd, het moment van ontvangst op de server, het moment van versturen vanaf de server en de ontvanger ontvangt dat dan ook weer op een tijdstip. Met die 4 tijden is de heen en de terug vertraging bekend en kan dus worden berekend hoeveel de lokale tijd afwijkt van de server. Daarna wordt de nieuwe tijd niet blind ingesteld, er wordt vergeleken met de andere servers en de lokale tijd (of zelfs tijden). En de tijd wordt altijd glijdend versteld: Elke seconde wordt geteld. Er worden milisecondes toegevoegd of weggelaten.

Bedenk dat de computers die wij gebruiken allemaal process-schedulers hebben die elk proces hun eigen tijd gunnen om te draaien. Daarbij zien de meeste processen niet elke miliseconde. Bij linux kan alleen de kernel met miliseconde nauwkeurigheid werken. Als miliseconde tijd nauwkeurigheid nodig is, dan zijn daar speciale systemen bij nodig en wordt geen klok-tijd gebruikt. Bij sport wedstrijden bijvoorbeeld wordt speciale hardware gebruikt.

[svenk91]

Daarom vond ik het zo vreemd dat het artikel suggereert dat de afwijking van ~4 microseconden van een NIST server impact heeft, gezien de foutmarges in andere systemen significant groter zijn in demorde van miliseconden). De suggestie dat die ~4ms afwijking in Boulder mogelijk impact heeft op laboratoria en ruimtevaart.

Ik ben ook even in het bron artikel gedoken, die zegt alleen dat je dit type nauwkeurige klok ook in die toepassingen vind, in een generiek stukje dat kort wat verteld over atoomklokken, niet dat ze specifiek deze NIST servers gebruiken. Ik denk dus dat het een gevalletje is van haastig vertalen.

[Robbierut4]

Due to prolonged high wind gusts there have been a combination of utility
power line damage and preemptive utility shutdowns (in the interest of
wildfire prevention) in the Boulder, CO area.

Ik ben telkens toch weer erg blij dat we in Nederland onze stroomkabels in de grond hebben zitten.

Is zeker niet perfect, maar ons netwerk blijft tenminste gewoon werken als we een beetje wind hebben.

[Mijzelf]

Nou ja, hier valt de stroom soms uit doordat een helikopter door de kabels vliegt. Niet alles ligt onder de grond.

[Robbierut4]

Dat is hoogspanning, dat heeft vgm ieder land boven de grond. (en dus het helikopter risico). Laagspanning ligt hier netjes onder de grond.

[laurxp]

Op de meeste plekken, maar nog niet overal! Langs de A12 ten zuiden van Bodegraven zijn er bijvoorbeeld een aantal woningen met bovengrondse stroomkabels.

[CH4OS]

Want in de grond kan niets gebeuren? Ik heb waar ik woon paar jaar terug een stroomstoring gehad, kabel was doorgesneden of doorgebroken, weet niet meer precies wat de oorzaak was, maar het was wel een kabel in de grond.

[AtHomer]

Tijd blijft een interessant iets. Zelf heb ik veel DCF77-klokjes die zichzelf synchroniseren. De bron hiervoor ligt bij de PTB in Duitsland, daar hebben ze de atoomklok die ook de officiële tijd in Duitsland bepaalt.

De tijd kun je hier bekijken, en als je op de delta t klikt zie je het verschil met je eigen apparaat.

[Reactie gewijzigd door AtHomer op 21 december 2025 12:00]

[tedades]

Ik had 2 dezelfde DCF77 klokjes maar die liepen niet helemaal gelijk. Daardoor neem ik aan dat de kwaliteit van je klokje ook erg belangrijk is.

Een klok die DCF77 gebruikt zal gemiddeld accurater zijn dan een klokje die je zelf moet instellen, maar niet perse een die NTP gebruikt. Een DCF77 klokje doet vaak maar 1 keer per dag synchroniseren, als het kan in de nacht omdat je minder ruis verwacht. DCF77 is niet super snel, het kost ongeveer 1 minuut om een heel bericht te ontvangen. Daarna zal het klokje op zijn interne oscillator vertrouwen om niet in tijd af te wijken. Als je NTP zou gebruiken zou deze de tijd vaker kunnen ophalen doordat dit snel verloopt. Doordat het zo snel verloopt kunnen ze NTP ook gebruiken om de afwijking van je interne klok te corrigeren, dat lukt met DCF77 niet goed via het tragere RF signaal. Ik verwacht dat het daarom ook een probleem is dat je een klein verschil hebt in tijd bij NIST, omdat de getrainde klokjes nu denken dat ze waren aan het 'driften' in tijd terwijl ze zonder NIST informatie mogelijk al accuraat waren.

[AtHomer]

DCF77 is goed genoeg voor huis-tuin-en-keukengebruik. De meeste heb ik van de Aldi/Lidl, de AA of AAA-batterij(en) gaan meer dan 5 jaar mee. De oudste klokjes die ik heb syncen elk uur, de nieuwere om de 6 of 12 uur, dat weet ik eigenlijk niet precies. Maar het is wel fijn om een extra tijdbron te hebben, onafhankelijk van het internet.

[Reactie gewijzigd door AtHomer op 21 december 2025 23:03]

[2400baud]

Heeft dergeijke minimale schommelingen nog invloed op certificaten en encryptie?

[laurxp]

Nee. De timestamp in TLS-certificaten heeft bijvoorbeeld een resolutie van 1 seconde. In de praktijk moet je d'r vanuit gaan dat er een time drift kan zijn van enkele seconden tussen client en server, dus zullen er geen protocollen zijn die een precisie van 1/1.000.000ste seconde vereisen.

Voor context: als een signaal met de snelheid van het licht reist, dan kan je in 4 microseconden zo'n 1199 meter afleggen. Één pakket versturen over een gigabit-verbinding duurt 12 microseconden. Je CPU heeft ongeveer 3 microseconden nodig om 1 MB aan lineaire data uit het werkgeheugen te lezen.

[2400baud]

Bedankt voor je heldere uitleg!

[beerse]

Niet bij jou en mij. In theorie wel bij de beurs-handel. Daar is het wie het eerst binnen komt.

[CH4OS]

Gelukkig zijn de meeste beurzen in het weekend gesloten.

[Reactie gewijzigd door CH4OS op 21 december 2025 22:03]

[Davey400]

4 microseconden klinkt niet als een gevolg van een spanningsonderbreking; de verklaring vind ik dan ook raar.

Een apparaat op gelijkspanning merkt niets van een dergelijke korte drop; elke condensator in de voeding is voldoende om dat te overbruggen. Een hik in de wisselspanning lijkt ook niet relevant; als de precisie daar van afhankelijk was dan hadden we andere problemen. (Dat is een cyclus van gemiddeld 50 of in de VS mogelijk 60Hz, met schommelingen die veel groter zijn dan die 4 microseconden.)

Ik ben dus erg benieuwd naar de werkelijke technische achtergrond van dit probleem.

Edit:
TL::DR: De 'stroomstoring' klopt, maar dat klokken stilvallen of daarvan schrikken dus niet; het syncen ná de storiing is dus wat verkeerd ging.

Van wat ik heb kunnen vinden zit het probleem dan dus ook niet in het stilvallen van de klokken; die zijn inderdaad gewoon netjes doorgegaan. Het is echter een redundant systeem bestaande uit meerdere klokken die onderling verbonden zijn.
Bij een spanningsval vallen de klokken dan ook niet uit, maar de onderlinge verbindingen kunnen wel wegvallen.
Dat is geen probleem; bij herstel van de verbinding komen die klokken weer in sync met de 'moederklok'; er is er simpelweg één leading.
Bij het syncen is het fout gegaan; de sync is niet 1 op 1, maar er is een gat van 4 microseconden, oftewel een x aantal pulsjes is daarbij verkeerd geteld. En ik snap dat dat een probleem is dat natuurlijk niet had moeten voorkomen.

Maar goed; dat is wat ik er nu van kon vinden en wat dus veel plausibeler klinkt als het oorspronkelijk in het nieuws gebrachte verhaal.

[Reactie gewijzigd door Davey400 op 22 december 2025 08:50]

[R_Zwart]

Je hebt helemaal gelijk. In de ideale wereld. Maar de wereld is niet ideaal dus soms gaan dingen fout fie niet fout horen te gaan.

[Hans1990]

Kan ook een verloop ipv uitval zijn. Idd 4us is als zodanig kort dat typische condensators nog niet ontladen zijn zou je zeggen.

Wellicht dat het sensing element van zo'n atoomklok dermate gevoelig is voor voedingspanningvariaties, dat deze tot 4us tijdsverloop heeft geintegreerd. Veel simpele elektronische schakeling zijn namelijk best wel gevoelig voor verloop, tenzij je met feedback, stroomspiegels of wheatstone bridges aan de slag gaat. Maar dat werkt goed op DC, niet zo goed op RF.
Tegelijkertijd, als het zo nauwgezet komt, had ik wel verwacht dat zo'n apparaat zulke parameters zou monitoren. Dus dat zou deze hypothese ook tegelijk ook kunnen ontkrachten.

Maar dit is even mijn gok ter waarde van 2 cent.

[beerse]

4 micro secondes. Met gelijkstroom is dat een spijker op de lijn. Met wisselstroom is het niet te meten.

Maar met jou internet verbinding van 1 Gbit gaan er 1.000.000.000 bits per seconde over de lijn. in 4 microsecondes zijn dat er 4.000. Die mis je dan mooi wel.

Er was overigens geen onderbreking van 4 microsecondes, de tijd afwijking was 4 microsecondes nadat er een stroomstoring was geweest wegens slecht weer. Dat is in de regel geen onderbreking maar vooral geknetter en vonken en andere storingen. Die komen ook op andere lijnen en verbindingen als storing binnen. Bij voorbeeld als storing op de antene van een atoom-klok-ontvanger.

[cheersmate]

In het geval van een tijdsregistratie die zo precies is en blijkbaar kan worden beïnvloed door een overschakeling op generatorspanning. Dan is het moeilijk te begrijpen dat er geen maatregelen zijn genomen om dit te voorkomen.

Wanneer een volledig datacenter schakelt van netspanning naar generatorspanning (en weer terug), dan is er altijd een schakeltijd van een fractie van een seconde. Dat is niet te voorkomen.

Wat wel te voorkomen is dat de systemen die voor de tijdsregistratie worden gebruikt daar door geraakt worden, door deze te voeden met batterijspanning (een UPS-systeem) in het rack waar deze in zijn geplaatst.

[osseh]

Precies dit. Ik kan me oprecht niet voorstellen dat systemen als deze niet op een UPS draaien.
Als dit niet het geval is dan is er ontwerp technisch gewoon echt een zeer domme fout gemaakt.

En tuurlijk hebben noodstroom systemen altijd even tijd nodig om over te schakelen, maar juist daarom zorg je ervoor dat alle systemen rechtstreek stroom krijgen van deze UPS.

Waar de UPS dan stroom van krijgt kan je dan laten afhangen van de situatie (uit de muur; zonnepanelen; noodstroom generator). Maar in die combinatie zou een systeem als deze nooit uit moeten kunnen vallen.

[CH4OS]

In een normale situatie zal zoiets vast wel geregeld zijn. Nu was er echter ook heel zwaar weer, wat een en ander complexer maakte. Als dan de netspanning er af gehaald wordt wegens brandgevaar, lijkt het me niet verstandig om dan ook van noodstroom voorziening te switchen of die systemen te starten...

[ernstoud]

Typisch business continuity issue weer... wel technisch helemaal voorbereid op uitval met noodstroomvoorzieningen e.d. maar de gebouwen waar deze staan zijn nu niet toegankelijk. En er is nu ook geen monitoring waardoor onbekend is wat er aan de hand is.

Als business continuity consultant (bij onder andere het Computer Uitwijk Centrum) meerdere van dergelijke situaties meegemaakt. Alles werkt, alleen Jan de systeembeheerder die weet hoe alles werkt is niet beschikbaar...

Mensen, Apparatuur, Programmatuur, Gegevens, Organisatie, Omgeving en Diensten noemt de Afhankelijkheids- en Kwetsbaarheidsanalyse dat. Ontbreekt bij een crisis een of meerdere componenten ben je weg.

[Roel1966]

Als je het mij vraagt, er zijn te veel verschillende systemen die niet met mekaar samenwerken waardoor je dan dit soort situaties krijgt. Ook vaak dan gebrek aan kennis van personeel en zoals je schrijft er dan maar 1 persoon is die niet 24/7 bereikbaar is. Zou denk ik al schelen als er eens een eenheid kwam en men veel meer met mekaar ging samenwerken en dan niet als het te laat is.

Zou daarbij ook nog willen schrijven van houd een analoog systeem als backup en vertrouw niet volledig op digitale systemen. Zorg er b.v. voor dat een generator simpel met een analoge knop gestart kan worden onafhankelijk van alle digitale koppelingen.

[ivorlandon]

Daarom liep mijn klok is dus niet meer gelijk! Ongekend dat zulke kleine tijden er toe doen

[R_Zwart]

Om het in perspectief te plaatsen: in een 5G TDD netwerk kan je gebruik maken van tijdsloten die een fractie van een microseconde zijn. 4ms heeft dan behoorlijk wat impact. Als eindgebruiker merk je het waarschijnlijk niet maar in het netwerk gebeurt dan behoorlijk wat. Nu zal deze verstoring geen impact hebben gehad omdat netwerken weer hun eigen tijd hebben die gesyncht wordt met de atoomklokken.

[un1ty]

4ms != 4 microseconde

4 microseconde = 4us. Zelfs in het netwerk gebeurt er niet super veel in zoon tijdsframe, maar iedere afwijking telt op en kan uiteindelijk wel een storing veroorzaken.

[GertMenkel]

Je hebt gelijk dat het om microsecondes gaat, maar 5G's TDD-algoritme verdeelt tijdslots die zo klein als 15,6 microsecondes kunnen zijn. De verstoring is dus een kwart van het tijdframe. Als de sync niet goed loopt zullen de slots minder precies moeten worden en kun je ordegroottes aan theoretische doorvoer verliezen.

Nu is het in principe alleen maar nodig dat ieder apparaat het eens is over de tijd, dat hoeft niet per se de juiste tijd te zijn, maar zulke kleine ordegroottes van verstoring kunnen wel degelijk storingen veroorzaken.

[BernardV]

De afwijking ging om microseconden, dus een factor 1000 t.o.v. ms.

Bij mijn weten zijn die frames ongeveer 10ms, dus als daar 4µs afwijking in zit is dat weinig (0.04%).

[PolarBear]

Maar heeft 5G TTD een externe klok nodig? Of is het gewoon een tijdslot van microseconden (of fracties daarvan).