AMS-IX introduceert satellietonafhankelijke NTP-dienst

AMS-IX introduceert de eerste commercieel beschikbare NTP-dienst die onafhankelijk van satellieten werkt. Het bedrijf levert de tijd met Private NTP via glasvezel. De officiële tijd wordt bij Nationaal Metrologisch Instituut VSL opgehaald. De maximale afwijking zou volgens AMS-IX minder dan een milliseconde zijn.

Zulke nauwkeurigheid is voor verschillende digitale processen essentieel, schrijft AMS-IX. Zo kan niet-nauwkeurige tijd leiden tot mislukte transacties in de financiële sector. Ook voor onder meer logging en cybersecurity is nauwkeurige tijd van belang. AMS-IX levert zijn Private NTP-dienst binnen datacenters die zijn aangesloten op AMS-IX.

De meeste organisaties gebruiken satellietgebaseerde NTP-systemen zoals GPS. Deze zijn kwetsbaar voor storingen, spoofing of uitval. Bovendien is het GPS-systeem eigendom van de Amerikaanse overheidsorganisatie United States Space Force. Tweakers schreef eerder al een achtergrondartikel over het Network Time Protocol en de kwetsbaarheden ervan.

"De systemen waarvan onze economie en samenleving afhankelijk zijn, moeten betrouwbaar en geloofwaardig blijven", zegt Peter van Burgel, ceo van AMS-IX. "Door een onafhankelijk tijdsignaal te leveren, afkomstig van VSL, helpen we organisaties risico's te verminderen, de continuïteit te waarborgen en te voldoen aan compliance-eisen." Uiteindelijk wil het bedrijf nog nauwkeurigere tijdsdiensten leveren voor onder meer energiebedrijven en automobielsystemen.

Reacties (89)

[beerse]

Als je serieus met tijd en ntp om gaat, gebruik je meerdere referentie klokken, liefst met meerdere technieken. In dat licht is deze 'niet satelliet' garantie een welkome aanvulling. En laat je de lokale ntp implementatie zelf de verschillende klokken vergelijken. In de meeste linux distributies kan gebruik gemaakt worden van de ntpd of de chronyd. Elk heeft daarin haar eigen voordeel en nadeel en ze gaan elk bewust met de tijd en ook met de onderliggende systemen om.

Bedenk dat het gebruikte operating systeem ook onderdeel is van de nauwkeurigheid van de klok. De scheduling van het operatingsysteem zorgt er immers voor dat de deamon/service op bepaalde tijden wel en niet beschikbaar is. Zeker als de gewenste nauwkeurigheid in de buurt van de milisecondes komt wordt dat relevant.

En als je dan in een virtueel systeem naar de nauwkeurigheid kijkt, dan is het niet alleen de scheduling van het operating systeem van de gast maar ook de scheduling van de host waarin het vrituele systeem draait. Dat maakt de nauwkeurigheid van de klok nog minder stabiel.

In een grijs verleden heb ik al eens testen gedaan met diverse ndpd implementaties op fysieke servers met linux en vmware-esx, virtuele servers (onder vmware-esx) en ook een raspberry-pi, een (cisco) router en een laptop. Uiteindelijk gezien dat de fysieke implementaties niet veel voor elkaar onder deden zolang ze niet te zwaar belast werden. Virtuele systemen leken best wel nauwkeurig maar zwabberden wat meer met de tijd.

[batjes]

Hier zit een voordeel dat we geografisch naast Duitsland liggen m.b.t. het dcf77 signaal. Dit kan een mooie extra bron worden.
GNSS is niet in elk datacenter mogelijk, dcf77 signaal binnen ontvangen net zo min. Maar een connect met de AMS-IX hebben ze vrijwel allemaal wel.

Het signaal hoeft ook niet 100% accuraat te zijn qua tijd, wat belangrijker is, is dat je eigen systemen allemaal op dezelfde tijd zitten.

Mocht je wel eens troubleshooten over verschillende systemen kan een milliseconde verschil betekenen dat bepaalde packets in een andere volgorde komen te staan.

Er zijn overigens een paar leuke Europese spelers die NTP systemen ontwikkelen.

[beerse]

Voor ntp dat via net internet wordt gevoed maakt de geografische plek niet zo heel veel uit. Wel het aantal hops en de mogelijke/gebruikte routes.

Voor ntp gaat het er vooral om dat de tijd zo stabiel mogelijk is. Dus ook de route via het netwerk zo stabiel mogelijk. Liever een klok die altijd op 12 hops weg staat dan een klok die de ene keer via 4 hops en de andere keer via 6 hops routeert. Een tool als 'traceroute' kan hier wat inzicht in bieden. Maar ook `ntpq -pn` of `chronyc -n sources` (en je goed informeren wat de getallen betekenen).

[Tozz]

Ik zou zeggen dat het aantal hops irrelevant is. Waar jij denk ik op doelt is je jitter. Die wil je zo strak mogelijk hebben.

[beerse]

Iedere hop is een buffer en dus een vertraging. Dat veroorzaakt jitter. Maar iedere hop is ook de kans op een andere route en dus een verandering van de tijd die het bericht nodig heeft.

Het ging er mij vooral om dat landsgrenzen voor tijd-gebonden verkeer over internet op zichzelf niet echt een issue zijn. Het is meer het aantal hops en de route die de berichten nemen. Eind vorige eeuw (toen werkte ik in de telecom) heb ik gezien dat internet verkeer van NL naar de USA sneller ging dan van NL naar Frankrijk of Duitsland. Soms ging het verkeer van NL naar Frankrijk wel eens via de USA, Tegenwoordig is internet veel meer vermaasd (er zijn veel meer verbindingen) dus zal het niet zo snel de wereld rond gaan.

[demianmonteverd]

Ik weet niet of het nog veel gedaan word, maar vroeger zag je wel DC's in eigen beheer en dan had men een antenne doorvoer naar het dak hiervoor.

[barbarbar]

Voor tijdkritische taken heb je realtime systemen en operating systems. Dan weet je met 100% zekerheid dat een taak op een bepaalde tijd en duur uitgevoerd wordt. Voor veel systemen is het echter voldoende om een accuraat tijdstempel op een transactie te hangen, dat de transactie zelf dan wat eerder if later wordt verwerkt maakt niet zoveel uit, zolang iedereen het er maar iver eens is welke volgorde correct was.

[baseoa]

Voor veel systemen is het echter voldoende om een accuraat tijdstempel op een transactie te hangen, dat de transactie zelf dan wat eerder if later wordt verwerkt maakt niet zoveel uit, zolang iedereen het er maar iver eens is welke volgorde correct was.

Als de volgorde het belangrijkste is en niet de tijdstempel, is het veel eenvoudiger om 1 centraal systeem te hebben waar je een 64-bit sequentieel volgnummer kan opvragen voor je transactie, in plaats van complexe tijdsynchronisatieprotocollen tussen interne systemen. Een schoenendoos op 1gbps kan honderdduizenden nummers per seconde uitsturen en met 64 bits ben je dan 146000 jaar voorzien. De tijd kun je dan gewoon uit NTP halen omdat die niet meer relevant is voor transacties (die ook in dezelfde milliseconde kunnen gebeuren) uit elkaar te houden

[Reactie gewijzigd door baseoa op 21 april 2026 17:02]

[barbarbar]

Het hele probleem met financiële transacties, en vele andere domeinen, is dat een centraal systeem niet mogelijk is. Je zit juist vast aan een decentraal systeem wat op één of andere manier tot één en dezelfde uitkomst moet leiden, ongeacht op welke plek een transactie wordt afgehandeld.

[baseoa]

Heb je daar een voorbeeld van? Ik kan me zo niks bedenken in de financiële wereld namelijk. Er lijkt altijd een centrale partij te zijn zoals Mastercard die de betaling verwerkt, Swift die de transacties tussen banken doet, een beurs waar je koop/verkoop-order geplaatst en gematcht wordt met andere orders, enz.

[Reactie gewijzigd door baseoa op 21 april 2026 19:42]

[barbarbar]

Lees je maar eens in hoe creditcard transacties worden verwerkt. Dat is zeker geen centraal systeem.

[baseoa]

Als ik daarop zoek en door de berg aan troepresultaten (creditcardaanbiedingen of -vergelijkingen) een relevant artikel vind, zie ik daar al in de eerste stap:

Credit card processing includes three major steps. First comes authorization, which basically requests your card’s details and gets permission for the transaction from the issuer and network.

Het gaat gelijk al langs de uitgever. Hoezo dit is niet centraal? Kun je iets minder dismissive zijn qua "lees je eens in" (terwijl ik juist vroeg naar informatie) en gewoon een gesprek erover voeren of zeggen waar de info te vinden is?

[barbarbar]

Het gaat niet meer over het artikel als we het over zulke dingen gaan hebben. Vandaar de korte reactie.

Uitleg credit card proces

Dat is een een stukje uitleg hoe het globaal werkt, dat laat al zien dat je met zoveel partijen werkt dat je al ziet dat het een decentraal systeem is. Maar dan nog mis je een flink stuk detail qua techniek zelf, als je de Wiki van Cobol bekijkt, geeft dat wel een idee van hoe complex het afhandelen van een simpele transactie eigenlijk is.

[dbijen]

Het aantal mensen dat niet weet waar UTC vandaan komt is een beetje schrikbarend. Satellieten zijn niet "de" bron van tijd maar synchroniseren hun tijd met de officiële Universal Coordinated Time (UTC).

UTC wordt bepaald aan de hand van honderden atoomklokken van nationale laboratoria wereldwijd.

Navigatiesatellieten kunnen een bron (Stratum 0) voor NTP zijn, maar zijn niet de primaire bron voor UTC. Dat zijn in principe de atoomklokken van de nationale instituten die samen de officiële tijd meting coördineren.

[The_MAN]

Zelfs beter, UTC bestaat niet op dit moment. GPS haalt zijn tijd van UTC(USNO) en die wordt via de BIPM Circular-T weer vergeleken met UTC, nadat UTC berekend wordt aan de hand van de aangeleverde gegevens van de atoomklokken. Nogal een probleem als je onder de ns zit met tijd synchronizatie, je kan nooit zeggen dat je onder ns accuraat bent naar UTC. <1ns accuraat vergeleken met UTC(PTB) of UTC(NIST) kan dan weer wel, want die tijdschalen bestaan in het heden

Erg interessant als je er in duikt, wordt nog leuker als je gaat bedenken dat 1s gebaseerd is op 9,192,631,770 trillingen van een Cs atoom, maar er optische klokken zijn die veel precieser zijn dan dat. Ze zijn dan ook vandaag de dag bezig om de seconde op nieuw te defineren.

[exyll]

Mis. UTC is kalender tijd, satellieten gebruiken echt verstreken aantal secondes sinds GPS epoch ergens begin 1980. Om de juiste kalender tijd te krijgen moet je .er schrikkelsecondes werken. Deze zijn opgenomen in de populaire TZ database

Oftewel GPS is niet UTC

[uiltje]

Grappig genoeg lijk jij er een van te zijn als ik de berichten onder je post leest. Maar goed, ik denk dat voor de meeste hollanders en vlamingen het niet al te veel uitmaakt waar UTC vandaan komt. Of de kilo etc. etc.

[AtHomer]

In Duitsland is het PTB verantwoordelijk voor de officiële tijd. Zij stellen ook NTP-servers beschikbaar.

ptbtime1.ptb.de
ptbtime2.ptb.de
ptbtime3.ptb.de
ptbtime4.ptb.de

The time servers are synchronized - independent of GPS - to UTC (PTB) by PTB's atomic clocks. Bron.

[Reactie gewijzigd door AtHomer op 21 april 2026 11:24]

[ThinkPad]

En zij zijn de bron voor het DCF77-tijdsignaal wat je radiografische klok die je mogelijk thuis hebt staan gebruikt

[AtHomer]

Ja, daar ken ik het PTB oorspronkelijk van. Ik vind het geweldig dat we nog een manier hebben om ook zonder internet te weten hoe laat het (bijna) precies is.

[MaartenBW]

VSL is de officiële tijdbewaarder van Nederland:

https://www.vsl.nl/vsl-tijd/


ps: Was ik de enige die de termen metrologie en meteorologie door elkaar had gehaald? metrologie -> meten; meteorologie -> weer

[Reactie gewijzigd door MaartenBW op 21 april 2026 11:49]

[Muncher]

Ik juich elke stap toe die NTP robuster maakt. Waar ik wel benieuwd naar ben is: waar haalt het Nationaal Metrologisch Instituut VSL de exacte tijd vandaan? Als deze alsnog de tijd van verschillende satellieten binnen hengelt, heeft de AMS-IX dan niet het risico doorgeschoven? Kan alsnog valide zijn hoor, daar niet van, maar ben benieuwd hoe het eigenlijk zit. Het persbericht lijkt daar niets over te zeggen.

edit:
VSL lijkt met de VU te werken aan een backup systeem waardoor er minder afhankelijkheid is van GPS en Gallileo. Misschien is dat waar hier gebruik van gemaakt gaat worden? https://www.vsl.nl/nieuws/vu-en-vsl-werken-samen-aan-robuuste-nederlandse-tijdsinfrastructuur/

[Reactie gewijzigd door Muncher op 21 april 2026 10:50]

[Sine]

Het VSL heeft zelf vier 5071A Cesium Primary Time and Frequency Standards

https://www.microchip.com...-clocks/cesium-time/5071a

https://www.vsl.nl/vakgebieden/tijd-frequentie/

Wil je meer info (tot op de interne werking van deze klokken) dan doet CuriousMarc een deepdive in een oudere variant van dit type klokken. Tot en met reparaties op componentniveau.
YouTube: How an Atomic Clock Really Works: Inside the HP 5061A Cesium Clock


Overigens hebben ze ook een publieke NTP server
Name: ntp.vsl.nl
Address: 31.223.173.226

Waarom je dan bij AMS-IX een service zou afnemen? Of ik mis iets ...

[Reactie gewijzigd door Sine op 21 april 2026 11:21]

[Belboer]

Ik vermoed dat je het dan over een apart netwerk krijgt zodat je zo min mogelijk last hebt van delay en jitter.

[beerse]

Binnen (of buiten/on-top-of) het ntp-protocol zijn er mogelijkheden om met een hogere nauwkeurigheid te werken dan de standaard ntp.

Daarnaast zal de route tussen jou systeem en die van de ntp-service ook beter zijn vastgelegd dan routering via al de netwerken die samen het internet vormen.

[The_MAN]

VSL heeft 3 Cs en 1 Active Hydrogen Maser tegenwoordig: BIPM Time Dept database

De VSL NTP server geeft je 0 garantie hoe accuraat het is in het datacenter als je daar je client hebt staan, AMS-IX wel.

[Kees]

Die verschillende satellieten hebben natuurlijk atoomklokken aan boord. Het is relatief eenvoudig om een satelliet niet de ruimte in te schieten en de atoomklok gewoon in het gebouw te houden. Je hoeft er dan niet eens een satelliet omheen te bouwen. Op dit moment hebben ze blijkbaar vier van deze klokken.

En dat doen ze samen met 85 andere organisaties die samen 450 atoomklokken hebben. En elke maand nemen ze het gemiddelde van die tijd en dat is de officiele tijd (https://www.vsl.nl/publicaties/dankzij-white-rabbit-staan-alle-horloges-gelijk/)

[Reactie gewijzigd door Kees op 21 april 2026 11:01]

[NoUser]

Lang geleden gehoord waarom het er vier zijn:
-Eén klok, dan weet je niet of de tijd juist is.
-Twee klokken, dan weet je niet welke de juiste tijd aangeeft.
-Drie klokken, indien twee gelijk lopen, weet je dat de derde niet correct is.
-De vierde is reserve, voor als er een klok defect raakt.

[-weenie-]

Maakt dat het dan RAIT ? Redundant Array of Independent Timedevices ?

[Kees]

Klopt, net zoals iemand met 1 horloge een tijd weet, maar iemand met twee horloges nooit zeker weet hoe laat het is

[pimlie]

Staat de vierde dan normaliter uit? Want wat als er twee klokken gelijk lopen met de andere 2 klokken?

Of maakt dat niet uit omdat ze in de praktijk toch altijd het gemiddelde van de klokken nemen?

[NoUser]

Wat ik mij nog meen te herinneren tikt de vierde wel mee maar wordt niet ‘uitgelezen’.

[beerse]

In dat geval is het ook leuk te kijken naar een Raspberry-Pi met de standaard linux installatie. Die heeft geen ingebakken 'bios'-klok. Dus weet ze bij het opstarten niet hoe laat het echt is. Wel zet ze als ze draait zo af en toe de huidige tijd in een bepaald bestand in de root. (met het `touch` commando). En bij het opstarten begint ze met de klok op die tijd te zetten. Daar heb je een mooi voorbeeld van die 4e klok.

[Reactie gewijzigd door beerse op 21 april 2026 15:47]

[Zsub]

Ik had precies dezelfde vraag. Dit artikel geeft een stuk meer achtergrondinformatie: Dankzij White Rabbit staan alle horloges gelijk - VSL

[GarBaGe]

Kan ik deze ook als NTP gebruiken?
Ik gebruik nu: europe.pool.ntp.org

[Dyon_R]

Edit: Na beter lezen is dit wel via GPS, dus mijn opmerking is onjuist! Oeps!

[Reactie gewijzigd door Dyon_R op 21 april 2026 10:40]

[Riesch]

Hmm IPv4 only?

Aparte keuze...

host time1.ams-ix.net
time1.ams-ix.net has address 198.99.141.1

❯ host time2.ams-ix.net
time2.ams-ix.net has address 198.99.141.2

[Nathabeer]

Ja, iets met vendor support en firmware! Maar! We zitten er kei-hard op te duwen, en we verwachten uiteraard ook IPv6 te ondersteunen in de zomer (ja, ik werk bij AMS-IX)

[xxs]

Is dat handig in de zelfde IP range? Bij een verstoring in die range heb je geen backup meer of is dat anders geregeld?

[Ascension]

Dat de IP-adressen achter elkaar zitten hoeft helemaal niet te betekenen dat ze in hetzelfde netwerk zitten. Ze kunnen zelfs aan de andere kant van de wereld staan. Het zou me niks verbazen dat ze anycast gebruiken voor deze servers zodat dit IP-adres altijd bereikbaar is en je automatisch naar een backup node wordt gerouteerd. De Google of Cloudflare DNS (8.8.8.8 en 1.1.1.1) werken hetzelfde, je wordt automatisch naar de dichtstbijzijnde server gerouteerd, dat betekent dus dat jij antwoord krijgt van een andere server dan ik terwijl we hetzelfde IP-adres gebruiken.

[arjankoole]

precies, ik had ook dat soort setups. Soms tussen dc's in nederland, soms de oceaan over. Werkt altijd.

[xxs]

Dank, niet aan gedacht.

[Tozz]

Ehm. Nee. Op Internet hebben we nog altijd een maximale prefix lengte van 24 netwerk bits. Dat betekent dat 198.89.141.0-198.89.141.255 altijd als 1 netwerk op Internet wordt aangeboden.

Het is daarmee onmogelijk dat de .1 in Europa uit komt terwijl de .2 aan de andere kant van de wereld uitkomt.

Je kunt het netwerk 198.89.141.0/24 wel 'aanbieden' vanaf meerdere locaties (Anycast), maar alle 255 IP's in dat blok komen vanuit perspectief van 1 gebruiker altijd allemaal uit op 1 plek. Oftewel, dan komen de .1 en de .2 beide uit in China. Of in Amsterdam. Of in New York.

[Ascension]

Dat hoeft niet. Binnen het AS kan het alsnog heel anders gerouteerd worden. Ook kan diezelfde /24 op meerdere locaties worden geadverteerd.

[Tozz]

Ja, theoretisch kan je in een AS het inderdaad weer anders routeren. Maar nu even realistisch.. Die .2 gaat echt niet intra-AS naar de andere kant van de wereld.

[baseoa]

Dat de IP-adressen achter elkaar zitten hoeft helemaal niet te betekenen dat ze in hetzelfde netwerk zitten.

Dan moet GBP wel eerst updaten als de ene site down is, toch? Anders stuurt je ISP of transitprovider traffic naar een systeem dat lam ligt. Wanneer het twee aparte ranges zijn, heb je die downtime niet en kun je direct het andere systeem vragen. Zover ik weet kun je een v4/32 of v6/128 niet wereldwijd announcen, dus zouden twee IP-adressen na elkaar wel degelijk storingsgevoeliger zijn dan twee onafhankelijke IP's in losse ranges

[Tozz]

Heh, dat is wel belabberd

[boswandeling]

Today, we’re introducing Time-as-a-Service (TaaS), the first commercially available service to deliver a reliable and redundant time signal. The service reduces dependence on external satellite systems and strengthens critical digital infrastructures.

Voor wat ekkies per maand denk ik wel dat je die kan gebruiken.

Ze hebben ook een publieke gratis NTP dienst maar die gaat over GPS en Galileo
https://www.ams-ix.net/ams/service/public-network-time-protocol-ntp/learn-more

[Reactie gewijzigd door boswandeling op 21 april 2026 10:42]

[IStealYourGun]

Met welke meerwaarde?

[Kees]

Als je financiele transacties doet en je wil niet dat je gebruikte tijd meer dan 100 nanosecondes afwijkt van de officiele tijd bijvoorbeeld.

Maar voor huis-tuin-en-keuken gebruik is de ntp pool prima. Die monitored zichzelf en als een server daarin meer dan 20 milisecondes afwijkt van de rest dan gaat die server uit de pool. Zelf heb ik heel lang een virtuele machine in die pool gehad die zelf de tijd bij stratum-1 providers ophaalde (en dus een stratum-2 provider was). En die liep eigenlijk nooit meer dan 1 miliseconde van het gemiddelde vandaan.

[mcmd]

In de financiële wereld gebruiken ze voor transacties niet NTP maar PTP

[adejoode]

PTP maakt ook onderdeel uit van de TaaS dienst van AMS-IX, die alleen niet gratis beschikbaar op een publiek netwerk.

[Alfa1970]

Ik vind het eerlijk gezegd wel een valide vraag.

Ik denk dat één van de mogelijke toegevoegde waardes zou kunnen zijn dat deze service minder gevoelig kan zijn voor verstoringen van buitenaf dan een publieke service die iedereen toelaat.

In het artikel wordt alleen 1 milliseconde gemeld als maximale afwijking. Dus ik denk niet dat de 100 nanoseconde die je noemt een factor zal zijn in de toegevoegde waarde.

[gpon]

Latency speelt hier een grote rol. Je kunt beter de lokale NTP server pakken die bij je provider staat.

[L00_Cyph3r]

Dat is nou het mooie van NTP, latency speelt geen rol, jitter wel tot op zekere hoogte.

[baseoa]

En die twee gaan hand in hand

Niet in een bijna-perfect systeem zoals als je met een satelliet praat bij Jupiter (fun fact: daarom kun je op aarde het zwaartekrachtveld van Jupiter meten als een sonde in Jupiter-omloop slechts een constant, dataloos signaal uitstuurt), maar op een packet-switched netwerk heb je bij elke hop kans dat er iets tussenkomt. En alleen de layer 3 (IP) hops zijn zichtbaar, dus als je door vijf layer 2 (bijv. ethernet) switches gaat en dan bij een router uitkomt dan heb je vijf keer die kans terwijl traceroute maar één hop toont. Bij hoge latency is het dus in de praktijk (iig op internet) wel het geval dat je ook veel hogere jitter zal zien en een minder precieze en nauwkeurige tijdsynchronisatie hebt

[L00_Cyph3r]

Je hebt helemaal gelijk, maar voor 99% van de gebruikers van NTP (ook zakelijk), is pool.ntp.org dikke prima.

Maar goed, hier op Tweakers zijn wij heer en meester in het vinden van edge-cases 😎

[beerse]

Als je nu erope.pool.ntp.org gebruikt, krijg je mogelijk een referentie klok van verder weg. Door je te richten op nl.pool.ntp.org heb je al meer garantie dat de klokken dichterbij staan.

Daarbij zou ik niet 1 maar liefst 3 of meer referentie klokken opgeven. Dus ook je eigen internet-toegang-provider (want die zit lekker dichtbij) en eventueel ook deze nieuwe gewoon toevoegen aan je configuratie en zien of ze mee gaat doen in jouw software.

Zie je eigen software (ntpd, chronyd...) hoe je de resultaten ziet van je eigen configuratie.

[Jermak]

Of ntp.time.nl

[Qwerty-273]

Zijn er nog organisaties die zelf wat NTP servers draaien? Bijvoorbeeld van Meinberg? Ja dat zijn niet zelf bron klokken, ze linken nog steeds naar satelieten (of een andere NTP bron) maar houden wel een strakke timing zelf aan. https://www.meinbergglobal.com/english/products/ntp-time-server.htm

[ThinkPad]

TimeNL (van SIDN) gebruikt o.a. die hardware: https://time.nl/#backgroundinfo en biedt hun diensten aan via ntp.time.nl

[beerse]

Eigen ntp-servers is wat anders dan eigen hardware-klokken. Maar om het even welke in gebruik zijn, ze hebben praktisch allemaal de mogelijkheid om zich te vergelijken met andere klokken. En dat wordt dan ook netjes in de specificaties vermeld.

En ja, satellieten met een goede en nauwkeurige klok aan boord zijn in de regel zeer stabiel en hebben een gekend pad met vertraging waarmee ze dus goede referenties zijn. En de protocollen die gebruikt worden zijn allemaal zodanig dat ze niets voor lief nemen maar alles met elkaar vergelijken voordat de eigen tijd wordt aangepast naar iets wat uit een referentie komt.

[ThinkPad]

Onlangs thuis even bezig geweest met NTP. M'n vaste devices aangepast zodat ze de tijd ophalen bij m'n OPNsense router (die heeft al een NTP-server aan boord) i.p.v. 'time.windows.com' en NTP pool etc. OPNsense zélf stond standaard ingesteld om de NTP Pool te gebruiken, maar ik ben liever niet van één partij afhankelijk (het is natuurlijk een pool, maar bijv. de 'ntp.org' domeinnaam is wel bij één partij in beheer). In het bovengenoemde Tweakers-achtergrondartikel werd bijv. ook beschreven dat als je verbind met de NTP Pool, de kans groot is dat je regelmatig bij NTP-servers van Cloudflare uit komt.

Iets meer spreiding vond ik wel wenselijk en dus heb in OPNsense de volgende servers ingesteld:

• 0.nl.pool.ntp.org
• ptbtime1.ptb.de (dit is ook de bron voor het DCF77 tijdsignaal!)
• ntp.vsl.nl
• ntp.time.nl
• time.esa.int

Zitten meerdere stratum 1 servers tussen, die als referentie dus hun eigen atoomklok hebben (PTB, VSL, TimeNL, ESA) want ook GPS valt te jammen/spoofen.
ntp.time.nl zit overigens al in de pool, maar dat zat PTB in het verleden ook en nu niet meer dus verwijs liever direct naar ze (is van SIDN: TimeNL).

Ik zou nog een stapje verder kunnen gaan door een GPSGNSS-ontvanger aan m'n OPNsense router te hangen als tijdsbron, maar dat vind ik weer een beetje overkill omdat ik die nauwkeurigheid niet nodig heb. Door de systemen thuis allemaal van hetzelfde apparaat de tijd op te laten halen zorgt er in ieder geval voor dat ze gelijk lopen met elkaar en scheelt weer wat (minimale) belasting op publieke NTP servers.

Het gelinkte achtergrondartikel over NTP is erg interessant trouwens.

[Reactie gewijzigd door ThinkPad op 21 april 2026 13:42]

[xxs]

Je kan eventueel ook kiezen om via DHCP (Ik gebruik dnsmasq) de ntp server te adverteren zodat je niet alle clients afzonderlijk hoeft te configureren.

[ThinkPad]

Ik geef het mee in de DHCP-opties (dnsmasq idd), maar er zijn volgens mij maar weinig besturingssystemen/apparaten die daar iets mee doen. Ik zag toevallig dat Chrony op Proxmox er wel naar kan kijken

Al m'n IOT spul wat in apart VLAN (zonder internet) draait en ik de tijdserver niet van kan aanpassen, buig ik met een DNAT-rule om zodat ze intern de tijd ophalen.

[Reactie gewijzigd door ThinkPad op 21 april 2026 13:32]

[Olaf van der Spek]

Onlangs thuis even bezig geweest met NTP.

Doe je aan high frequency trading thuis?

[YGDRASSIL]

De lampen moeten wel op de goede tijd aangaan natuurlijk

[beerse]

Als je nu kijkt naar de ip adressen die je krijgt op de genoemde dns-namen en dat over een paar uur nog eens doet, dan kan je zien dat de pool.ntp.org zo af en toe wisselen.

De pool.ntp.org ntp-servers zijn een wisselende en random greep aan de ntp-servers die zich bij pool.ntp.org hebben aangemeld. https://www.ntppool.org/nl/

En van een aantal van jouw andere gebruikte klokken, vermoedt ik een zelfde/vergelijkbare constructie.

[psdata]

Mooie leuke setup @ThinkPad , zelf draai ik ook zo iets van een config thuis en distributeer het intern zelf off via DHCP of vaste instelling op de device's zelf (laat VM en LXC containers) zelf hun tijd ipv bij hun host.

Maar voor wat klanten draaien we in hun (eigen hun DC's) toch een 4 tal Meinbergs (dedicated NTP device's) die ook mekaar in de gaten houden met ontvangst van zowel Internet tijd, DCF en GPS.

[bydvh]

Misschien handig om te weten: VSL is het "Nationaal Metrologisch Instituut"

[Imre Himmelbauer]

Ik voeg het nog toe!

[Hendry]

Kan je ook aan je artikel toevoegen wat NTP is?

[xxs]

Die streep onder de blauwe letters in het artikel is een link die je aan kunt klikken. Daarin staat haarfijn beschreven wat NTP is en doet:


review: Het Network Time Protocol - De wankele basis van kloksynchronisatie

[ASS-Ware]

Kan je ook aan je artikel toevoegen wat NTP is?

Network Time Protocol.

[baseoa]

Vroeg me al af of "nationaal meteorologisch instituut" misschien het KNMI van België is, maar dat heet KMI. Een NMI waar dan de afkorting "VSL" bij staat is echt niet verwarrend 😕

Edit: @MaartenBW geeft de oplossing elders in de reacties!

Edit edit: een @-mention en URL samen werken blijkbaar niet. De reactielink nogmaals.

[Reactie gewijzigd door baseoa op 21 april 2026 17:29]

[DjoeC]

Ben ik de enige die milliseconde nauwkeurig nogal "onnauwkeurig" vind? Als je transacties wilt timestampen lijkt me (minimaal) microseconden vereist, 10.000 transacties per seconde is in een grotere organisatie zoals bij high-frequency trading niet ongebruikelijk.

Ik heb thuis een Raspberry gebaseerde NTP server die zowel van internet (pool en specifieke) servers gebruik maakt en daarnaast GPS gebaseerd is. Die zit al in de "lage" microseconden qua nauwkeurigheid. Ik kan dat overigens niet controleren

[beerse]

De raspberry pi met een linux geïnstalleerd is en verder niet veel te doen heeft en in een stabiele temperatuur draait en een stabile voeding heeft, is al snel veel nauwkeuriger dan de gemiddelde virtuele server in een rekencentrum of een msWindows server.

Bedenk dat het multi-tasking van operating systemen een scheduler heeft die de nauwkeurigheid en de precisie bepaald wanneer de ntp-service aan de beurt is.

Als de raspberry-pi de ntpd service draait, is het commando `ntpq -pn` je vriendje. Mocht ze chrony (chronyd) draaien, dan is het commando `chronyc -n sources`. En je mag zelf in de documentatie uitzoeken wat de getallen allemaal betekenen.

Als je echt een hardware-klok hebt aangesloten op de R-Pi, dan is het wel leuk om in ntpd te zien dat ze ip-v4 adressen gebruikt in de 127.x.y.z reeks.

[toevoeging] Even op Wikipedia: ntpd gespiekt en gezien dat er best veel verschillende software implementaties zijn tegenwoordig....

[Reactie gewijzigd door beerse op 21 april 2026 16:13]

[DjoeC]

Ik draai Chrony op een Pi2 met een Adafruit GPS. Dan komt er dit uitrollen:

MS Name/IP address Stratum Poll Reach LastRx Last sample

==============================================================================

#x GPS 0 4 377 14 -529ms[ -529ms] +/- 106ms

#* PPS 0 4 377 23 +8ns[ -462ns] +/- 312ns

Na propagatie naar andere apparaten is het iets minder nauwkeurig:

MS Name/IP address Stratum Poll Reach LastRx Last sample

==============================================================================

^* ntp.local 1 8 377 201 +3861ns[+1954ns] +/- 259us

^- meron.soleus.nu 3 10 377 823 +9547ns[ +11us] +/- 2214us

@arjankoole Ik kan natuurlijk niet inschatten hoe vergelijkbaar tijdstippen tussen jou en mij vergelijken. Het gaat er bij mij vooral om dat lles intern goed op elkaar is afgestemd.

[Reactie gewijzigd door DjoeC op 21 april 2026 17:10]

[beerse]

in jouw voorbeelden zie ik dat je 2 refrerentie klokken gebruikt.Dat is het minst wenselijk, dan weet de lokale machine niet welke te gebruiken. Met 1 is dat wel duidelijk. Met 3 of meer kan ze het gemiddelde bepalen uit (een selectie) van de klokken om lokaal het beste resultaat te krijgen.

Je zou de meron.soleus.nu (of welke je dan ook geconfigureerd hebt) ook op de RPi toe kunnen voegen als extra zodat die er in ieder geval geen 2 heeft. Kan je ook 'eerlijk' vergelijken tussen de verschillende klokken.

[arjankoole]

m'n telefoon meld een precisie van 60 ns.

dat moet jij toch ook kunnen halen

[baseoa]

Waar "meld" je telefoon dat? Een ntp-client via adb of time.is of zo? Het klinkt voor mij, iig zolang je geen GNSS-lock hebt, wel als onwaarschijnlijk nauwkeurig

[Reactie gewijzigd door baseoa op 21 april 2026 17:33]

[cmpxchg]

Hoe krijg je die 60 ns puls dan naar buiten ? Via de 3.5 mm audio jack ? Die heeft een wel erg lage samplerate en slew-rate...

[beerse]

Het is meer waarschijnlijk dat jou telefoon meldt dat ze een afwijking ziet van 60 nano-secondes. De grote vraag is waarmee? En hoe stabiel is dat?

[cmpxchg]

Nanoseconden is al een miljoen keer (!) beter dan NTP's milliseconden, en is via GNSS / Galileo met een goede high-end ontvanger mogelijk (bijv Septentrio uit Belgie).

Fiber en sub-nanoseconde kan ook nog, bijv met CERN's fiber 'white rabbit'.

Wikipedia: White Rabbit Project

Het is open-source, dus in principe kun je hem zelf ook thuis bouwen... (als je de prijs van de high-end FPGA en PCBs ervoor over hebt...)