Ja die werkt wel goed inderdaad, is volgens mij zo’n Meinberg ding met multiple sources.
De experimentele “any.time.nl” (anycast) werkt een stuk minder goed.
Andere goede NTP servers: time1.google.com t/m time4.google.com
Leuk topic overigens. Stom toeval, ik host sinds deze maand zelf een publieke tijdserver.
Binnenkort.
Leuk! Zou je daar wat meer over kunnen vertellen?
Ik werk geruime tijd in IT en probeer altijd wat terug te geven aan de community. Om die reden heb ik bijvoorbeeld een tijd een Linux repository mirror server beschikbaar gesteld. Dat liep echter volledig uit de hand. Ik verstookte veel verkeer (TB uitgaand per dag) en het werd als hobby simpelweg te kostbaar. Je huurt een dedicated server met flink veel opslag en bandbreedte. Tel maar uit.
Mijn nieuwste project is dus een NTP-server. Eigenlijk is het heel simpel: een kleine Linux VPS met chronyd en een simpele configuratie. Verder draaien NGINX en vnStat om statistieken weer te geven in je browser. Ik ben onderdeel van de NL NTP Pool en wordt dus volop geraadpleegd door systemen om tijd te synchroniseren.
Het draait allemaal bij Vultr in NL waarbij ik ook de Vultr nameservers gebruik zodat ik indien benodigd gebruik kan maken van de DDoS beveiliging.
Server statistieken:
Samenvatting
Mijn pagina bij de NTP pool (incl. monitoring):
Samenvatting
Leuk project @Eirikr, zoiets is misschien ook wel een leuk project voor mijzelf 
Heb je nog bijzondere clocksources geconfigureerd voor je ntp server?
Ik ben Stratum 2 en sync vanaf Stratum 1 servers.
https://support.ntp.org/bin/view/Servers/StratumOneTimeServers
In mijn geval een aantal Nederlandse servers.
Er zijn ook leuke tools om e.e.a. realtime te monitoren.
Wat dan meteen opvalt is dat IPv6 vrijwel niet wordt gebruikt. Nog geen 5% van het verkeer.
Leuk.
Ik heb zelf een stratum 1 servertje (met nu 2 reference clocks en een 3e in de maak), dus dat is best leuk om te delen denk ik. Dit “servertje” is een RPi2B dus misschien niet heel geschikt om publiek aan te bieden, maar daar een extern beschikbare ntp server op laten syncen moet te doen zijn.
De verhouding v4/v6 herken ik wel. Ik draai al een tijdje een tor relay en ook daar blijft v6 flink achter op v4.
1 like
Cool, mag ik als kleine sidestep vragen hoe je dit bouwt / welke hardware je hiervoor hebt gebruikt ?
Ben zelf tijdje bezig geweest om op een Pi een DCF77 receiver aan de praat te krijgen die ik uit een oude klok heb sloopt maar dat wilde niet erg lukken
Natuurlijk mag je dat vragen
De basis is een Raspberry Pi 2B, daar op zit de Ultimate GPS HAT voor de GPS ontvangst. Voor de DCF77 ontvangst heb ik zo’n standaard module aan een ESP8266 geknoopt voor de decoding, die via USB-serial de tijd doorgeeft aan de Pi.
De software op de Pi is gentoo als distro. gpsd zie je vaak maar gebruik ik niet, ik laat ntpd direct tegen de GPS aan babbelen. De ultimate GPS HAT geeft ook een PPS signaal en daarmee is (met een beetje tunen) 1us nauwkeurigheid te halen. Daarna is de Pi de bottleneck, want PPS zou geloof ik tot 100ns nauwkeurig moeten kunnen zijn.
De software op de ESP8266 is zelf geschreven in lua icm. nodemcu. Die doet de decoding van DCF77 en geeft over de USB-serial GPS sentences, dus ntpd denkt dat hij tegen een tweede GPS babbelt. De stabiliteit van het DCF77 signaal uit de module valt me wel wat tegen, maar als het goed gaat haalt ook die een nauwkeurigheid van enkele milliseconden. Ik heb hier expres gekozen om de DCF77 processing op de ESP te doen, iedere extra belasting (en extra interrupts) op de Pi zorgen voor een verslechtering van de nauwkeurigheid van het PPS signaal. Denk bijvoorbeeld aan slechte ontvangstcondities waarbij de ESP nu soms duizenden interrupts per seconde voor z’n kiezen krijgt.
De derde (die helaas nog niet zo wil vlotten) zou een zelfde setup zijn als voor DCF77 maar dan met een MSF ontvangstmodule. Dat hangt nu vooral aan de (on)beschikbaarheid van die module 
Daarnaast synct de Pi ook met ntp.time.nl voor het geval al m’n eigen klokken om wat voor reden dan ook zouden falen. Uiteraard sync’en de rest van m’n systemen allemaal met (voor NTP) relatief hoge frequentie tegen de Pi.
2 likes
Hier een artikel voor RPI… (gelezen, niet gechecked).
Deze is voor RS-232/USB… Ik heb hiervan de variant voor RS-232 gebruikt toen de internet verbinding nog een behoorlijk brakke DSL verbinding was. Dit is buiten gebruik geraakt toen de moederborden geen standaard RS-232 meer hadden.
http://www.sput.nl/time/dcf77.html
Dit levert een PPS klok op.
1 like
Als je alleen DCF77 wil is dat inderdaad een goede optie. Het lastige in mijn geval was dat de enige hardware RS232 poort van de Pi (in de GPIO connector) al bezet is door de GPS. Een PPS signaal over USB is geen succes vanwege de jitter die de USB bus met zich meebrengt, daardoor verlies je veel van de nauwkeurigheid van het PPS signaal.
1 like
Dank goed verhaal! Gisteren me ook wat gaan inlezen op NTP stratum 1 setup bouwen en whoei da’s een stuk complexer dan ik dacht.
Qua DFC77 cindt ik de decoding intrigerend dus ga ik me nog wat verder in verdiepen, begrijp ik trouwens goed dat je de ESP niet via WiFi maar direct aan je Pi hebt hangen (USB serial) ?
Mocht je die code trouwens ergens publiek hebben staan dan houd ik me aanbevolen
Geen must maar vond het gewoon leuk om eens uit te zoeken, maar is 1 van de vele projecten die zo langzaam voort kabbelden of soms gewoon ook maanden stilliggen. Achterliggende idee was om de techniek achter DCF77 wat verder te leren kennen, en zelf een accurate klok te bouwen zonder afhankelijkheid naar mijn internet verbinding.
Klopt, ik gebruik de wifi mogelijkheden van de ESP totaal niet (ik heb sowieso geen actief wifi netwerk in huis ). Ik heb de nodemcu sowieso zo gemaakt dat er alleen de modules in zetten die ik nodig heb, dat scheelde weer een paar milliseconden :). USB gebruik ik sowieso voor voeding, en als ik ntp hem als gps wil laten benaderen heb ik toch een seriële poort nodig, win-win dus.
De code staat niet publiek en heeft nog een hoog knutselgehalte. Als je wil kan ik hem wel via PM met je delen en eventueel wat uitleg geven.
DCF77 decoding is op zich simpel: Per seconde krijg je een korte of lange puls (0 of 1), en met 59 bits heb je een volledige timestamp inclusief wat extra dingen als parity, zomertijd, enz., wat je op welke seconde krijgt is al op heel veel plekken te vinden.
Dat is zeker leuk en interessant. Bedenk wel dat mijn code dan misschien leuk is als inspiratie maar niet direct bruikbaar. Hij is opzettelijk zo gemaakt dat zodra het DCF77 signaal faalt (en dat gebeurd best vaak met de module die ik heb) dat dan ook direct de output stopt. In mijn geval is dat het gewenste resultaat want dan heeft ntpd namelijk door dat DCF77 niet meer bruikbaar is en zal hij andere keuzes gaan maken. Als je een klok wil maken die het altijd doet en alleen regelmatig z’n tijd synct met DCF77 is dat een heel ander verhaal.
1 like
Na m’n vorige post dacht ik ineens “Waarom zou ik de code eigenlijk niet publiceren?”, dus ik heb de code inclusief wat begeleidend schrijven inmiddels in m’n cgit gezet: dcf77_gps - Use a DCF77 receiver to pretend to be a GPS
Zoals gezegd heeft het nog een hoog knutselgehalte dus verwacht niet de mooiste code die ooit gezien hebt
1 like
Cool!
Ga ik ook eens proberen. Maar waar haal je eigenlijk het PPS signaal vandaan, wordt dat ook geleverd door de DCF77 module?
DCF77 is een puls per seconde signaal de lengte van de puls is een een of een nul.
59 is dacht ik geen puls maar een pauze om de 0 aan te geven.
Eerst minuut eenheden, dan tientallen, uur eenheden etc. Ik zou een oude map moeten doorzoeken voor de exacte specs… Maar ik ben nog even op reis.
Zoals @Noci al zegt: DCF77 is een PPS signaal. Door de lengte van de puls te variëren wordt er per seconde een bit meegestuurd en zo wordt er in een hele minuut een volledige tijd doorgegeven.
Synchronisatie bestaat dus uit drie fases:
- Detectie van een nette puls
- Wachten tot een nieuwe minuut begint (herkenbaar omdat de laatste puls per minuut ontbreekt)
- Een minuut lang pulsen ontvangen en decoden tot de werkelijke tijd
Daarna weet je pas hoe laat het is, daarom zeggen ze bij de ontvangers altijd dat synchronisatie een paar minuten duurt.
Nauwkeurigheid van de PPS van DCF77 ligt ergens in de milliseconden. Als je nauwkeuriger wil heb je GPS nodig. De betere GPS ontvangers geven ook een PPS signaal en die is in theorie 100nS nauwkeurig, in de praktijk bij mij op een Pi2B enkele microseconden.