[quote]Zolang alles van freedom bij BIT staat, waarom zou je die niet gebruiken.
Dat is de kortste weg.[/quote]
Dat is een denkfout denk ik. Dat “alles van freedom bij BIT staat” gaat wellicht over servers zoals een website, dit forum, etc. Maar dat betekent niet dat de weg naar BIT de kortste weg is! De gebruikers aansluitingen zijn op een andere plek aan internet gekoppeld dan de servers. Ik heb hier kortere pingtijden naar bijvoorbeeld XS4ALL dan naar de servers van BIT.
Even gekeken.
Klopt xs4all is korter.
Die doen ze vast binnenkort uit. 
Nee ik denk dat de abonneelijnen direct in Amsterdam zijn gekoppeld tussen Tweak DSL en de AMS-IX waar ze peeren met XS4ALL, en dat BIT in Ede daar ook aan hangt. je verkeer loopt dus niet “via” BIT, er staan alleen servers bij BIT.
Omdat XS4ALL ook in Amsterdam zit is de pingtijd daarheen lager.
1 like
Ik bedoelde dat ntp.xs4all.nl binnenkort wel door time.kpn.net vervangen zal worden.
Is ergens te achterhalen hoe kwalitatief goed een ntp-server is?
(hoe secuur, fail-momenten, uptime, enz.)
Wat doet een FritzBox als de daar opgegeven tijdservers niet te bereiken zijn?
(ik neem aan, tijd gewoon door laten lopen, afhankelijk van de 50 Hz op het stroom-netwerk)
Van de servers die (ook) meedoen in de ntppool, kan je de statistieken inzien. Zoals van ntp.time.nl en daar kan je dan ook per IP verder klikken en je kan dan ook een ander IP in je adresbalk zetten om te kijken of dat systeem ook in de pool meedoet en dus wat de statistieken daarvan zijn.
Secuur: NTP kan wel degelijk geauthenticeerd worden, dit is met name noodzakelijk wanneer multicast syncing gebruikt wordt.
Daarnaast kan het zijn dat time request packets gesigned moeten worden anders krijg je geen antwoord…
Dus ja het KAN, wordt het ook veel gebruikt dan dan weer niet zo.
Fail momenten is met name een netwerk of filter issue op firewalls. Maar je krijgt wel een rapport te zien over bereikbaarheid.
(reach kolom, octaal getal) 377 betekent dat de laatste 8 polls gelukt zijn, 1 betekent dat alleen de meest recente poll gelukt is. (0 = geen antwoord gezien). 40 zou betekenen 1 gelukte poll, gevolgd door 5 mislukte polls. poll kolom is het interval tussen polls. dit moet niet te land worden btw. (Bij elke poll request verzenden wordt er een shift left gedaan, en bij ontvangst van het antwoord wordt er or 1 gedaan)
Uptime van een klok/ klokserver is niet zo relevant.
Meer relevant is stabiliteit… en afstand.
1e: Afstand tot een nauwkeurige klok: = stratum … stratum 0 = atoom klok , of ander betrouwbare bron van tijd (GPS is ook de gemiddelde tijd van een 3tal atoomklokken in 2 technologieën (CS,H2) / satelliet), stratum 1 is de server die eraan hangt. Bij elke NTP server meer, wordt er een bij opgeteld.
2e: Afstand het aantal netwerk hops, snelheid van servers etc. af te leiden van delay.
3e: Afstand in tijd: offset (in micro seconden ).
Jitter is een maat voor stabiliteit. jitter = 0 is relatief extreem stabiel… (lees: loopt in de pas met de eigen klok…)
de klok met de laagste Jitter met een goede bereikbaarheid zal als primaire server gekozen worden.
Als je de machine klok (Hardware) mee wil vergelijken, dan kun je die opnemen (local clock), met een hoge stratum (15-19) dan zal die nooit gekozen worden maar heb je een mogelijk eikpunt.
Er zal gestreeft worden om gelijk te gaan lopen met de gekozzen referentie klok.
(* in linker kantlijn, + in linker kantlijn zijn de backup klokken.)
Bij afwezigheid van de tijd wordt er NERGENS mee gesynchroniseerd, de 50Hz van het net is NIET zichtbaar voor de systemen.
Een systeem kan op basis van de referentie klok vast stellen of de systeem klok fracties sneller of langzamer lopen…
Dan wordt de schedule interrupt zo nauwkeurig mogelijk op gelijke tred gezet.
(normaal gesproken wordt er zo’n 1024 keer / seconde een timer tick gegenereerd, maar indien nodig wordt dit naar 1023/sec of 1025/sec aangepast zolang de klokken maar gelijk lopen. )
1 like
Ik heb net een klein programma gedownload.
Het behoeft geen installatie.
Geeft wel inzicht over de server.
https://www.ntp-time-server.com/ntp-software/ntp-check.html
Wat ik ook doe, ik blijf er plm 500ms naast zitten, zegt de software.
Als je delay ook 500ms is dan is dat geen probleem…
btw: ntpq van je eigen klok levert meer relevante info op…
remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) .LOCL. 10 l 18d 16 0 0.000 +0.000 0.000
+ntp.xs4all.nl 193.67.79.202 2 u 62 128 377 0.892 +0.637 0.408
-ntp1.time.nl .MRS. 1 u 25 128 377 9.921 -2.495 6.296
*ntp0.nl.uu.net .GPS. 1 u 68 128 377 2.288 +0.653 0.371
+ntp1.nl.uu.net .GPS. 1 u 97 128 377 1.315 +0.642 0.365
Zie eerder stukje vooor reach, poll, delay jitter.
When is wanneer de vorige poll geweest is.
t = clock type (l = local, u=udp).)
remote het adres van een NTP server
refid = waar die betreffende NTP server de tijd van afleest. (MRS is multiple referene source)
Offset is het brekende tijd verschil, en zal een aanpassing van de eigen tijd tot gevolg hebben…
Als er te lange tijd tussen polls zit zal dat m.n. de jitter negatief beinvloeden door voershoot verscheinselen).
VM’s zijn notaire false tickers, ze missen vaak een paar kloktikken als een andere VM bezig is.
Momenteel gebruik ik de frizbox als server.
Volgens mij maakt het voor mijn toepassing ook niet zoveel uit.
Die delay naar de fritzbox varieert van 1 tot 23
Direct een externe server instellen in de pc, maakt het verschil alleen maar groter.
1 like
Dat hangt af van de kwaliteit van de software op je eigen PC. Als die Windows draait dan is de nauwkeurigheid slecht. Met Linux of BSD (Apple) kan die heel goed zijn, daar is de timing in de kernel veel beter geregeld.
Met ntpd zoals daarboven door Noci getoond kun je makkelijk binnen de 5ms komen (die “offset” die daar staat is in milliseconden!), gebruik je in plaats daarvan chrony dan gaat het nog beter.
Voor de allerbeste resultaten kun je een GPS ontvanger aansluiten op een seriele poort waarbij de “1 puls per seconde” uitgang op de DCD handshakelijn is aangesloten.
Daarmee kun je op een Linux machine binnen de 1 microseconde blijven.
(de absolute nauwkeurigheid zal minder zijn maar de drift en jitter blijven daar binnen)
Dit is uiteraard alleen voor specialistische toepassingen nodig, niet om het klokje in je taakbalk OK te houden.
2 likes
Op een Windows-pc die 24/7 een nauwkeurigheid op milliseconde-niveau moet hebben gebruik ik (gratis) software van Meinberg:
https://www.meinbergglobal.com/english/sw/ntp.htm
In combinatie met:
https://www.meinbergglobal.com/english/sw/ntp-server-monitor.htm
In ntp.conf heb ik ntp.time.nl als preferred server + drie Duitse ntp-servers.
NTP Time Server Monitor behoeft geen toelichting. Handleiding voor de installatie van NTP for Windows:
1 like
Zie ik iets over het hoofd? Iemand die behoefte heeft aan een zeer nauwkeurige tijd kan toch altijd een eigen NTP server inzetten met daaraan een GPS ontvanger gekoppeld? Voldoende instructies te vinden hoe je dat eenvoudig kan doen. Dit is een van de vele pagina’s gewijd aan dit onderwerp.
Ik denk dat het hebben van ISP-infra voor een provider als Freedom wel belangrijk is. Ik vraag me af of ze niet ntp.freedom.nl kunnen CNAME-en naar een NTP server van BIT, tot ze eigen spullen in een eigen ruimte hebben?
En om @HappyUser te beantwoorden: natuurlijk kun je een eigen ontvanger opzetten (dan wel drie, vanwege de betrouwbaarheid). Je kunt DVD’s huren in plaats van NetFlixen, brieven sturen in plaats van email. Snap je mijn antwoord?
Op zoek naar ‘de’ ntp service voor freedom.nl kom ik op deze draad uit. Als techneut die vaker met ntp heeft gehakt een paar aandachtspunten voor iedereen die tot hier is gekomen met lezen.
Niet elk operating systeem kan even goed gesynchroniseerd worden. Een unix en linux systeem kan veel stabieler werken dan een msWindows systeem. Dit heeft vooral te maken met technische details van de proces scheduler en omstreken.
Een ntp-server op een virtueel systeem is veel minder stabiel dan een ntp-server rechtstreeks op de hardware. Een Raspberry-Pi van de 2e generatie is stabieler dan elke virtuele server: de virtualisatie-scheduler maakt een virtuele ntp-service instabiel. Voor vmware-esx is het goed mogelijk de ntp van de esx-laag te gebruiken. Ook is het goed mogelijk de ntp-klok van fysieke routers te gebruiken.
De kwaliteit van een ntp-server is vooral bepaald door de stabiliteit. Beter een stabiele klok verder weg dan een instabiele klok dichtbij. Met verweg of dichtbij wordt vooral het aantal router-hops (van traceroute) bedoeld.
Het ntp protol kan heel goed met afwijkingen overweg als/zolang ze stabiel zijn en herkend worden door het gebruik van 3 of meer referentie klokken.
Over ntp en freedom.nl: het zou mooi zijn als Freedom ergens centraal een lijst met services beschrijft en daarin voor freedom klanten beschrijft waar/hoe deze diensten het beste te gebruiken.
Het zou mooi zijn als ze voor ntp een dns-alias maken (ntp.freedom.nl) die wijst naar de huidge geadviseerde ntp-server, of dat nu van hun leverancier is of van nl.pool.ntp.org maakt mij niet uit.
Het zou mooi zijn als/zodra ze eigen fysieke servers heeft, dat ze dan daar ook een ntp-service gaat draaien. En geheel in de freedom-filosofie ook mee gaat draaien in nl.pool.ntp.org. Maar dat is toekomst.
1 like
Voor wie gewoon simpel de Fritzbox gebruikt.
Ik heb het op dit moment zo ingesteld en het werkt goed.
En in Windows
2 likes
Waarom maak je niet gebruik van de nl pool?
Die heeft me een keer in de steek gelaten.
Met wat testen heb ik 3 goede gekozen.
Ik hoop als er een storing is, dat er minstens 1 blijft werken.
1 like
Servers uit de pool moet je eigenlijk alleen met SNTP gebruiken. Dwz op een bepaald moment wil je de tijd syncen, op dat moment doe je een DNS request, en doet een SNTP naar een of alle van de geretourneerde servers. Dan werkt het goed.
Als je de pool gebruikt voor het selecteren van servers in een “ntpd” (of chrony) die deze servers langdurig gaat gebruiken, of nog erger als je een handmatige lookup doet en dan de geretourneerde IP adressen hardcoded als server gaat configureren, dan word je natuurlijk afhankelijk van de kwaliteit en stabiliteit van die servers. En daar is niks over bekend.
Met SNTP via de pool DNS namen heb je daar geen last van want de DNS van de pool geeft alleen adressen terug waarvan de monitoring server recent heeft vastgesteld dat ze goed werken.
Recentere versies van ntpd die naast het “server” commando ook het “pool” commando kennen die gaan hier iets beter mee om. Als een server uit een “pool” statement geen antwoord meer geeft dan wordt er een nieuwe DNS lookup gedaan. Dus als je nu in /etc/ntp.conf hebt staan “server nl.pool.ntp.org” maak daar dan van “pool nl.pool.ntp.org”.
(dat kan uiteraard niet als je dit configureert in een of ander apparaat waar je alleen de naam mag opgeven)
3 likes
Zoals ik vele andere in dit topic zie had ik ook altijd het idee hoe dichterbij (netwerktechnisch) de NTP server hoe beter, en voor m’n overstap maakte ik dan ook graag gebruik van de NTP server van xs4all.
Sinds de overstap naar freedom sync ik met ntp.time.nl en tot mijn verbazing werkt die beter en stabieler (in jitter, delay en offset) dan de server van xs4all deed. Dus voor wie een goede NTP server zoekt zonder zelf iets op te willen zetten kan ik ntp.time.nl zeker aanraden.
Voor wie beter wil dan dat: Een raspberry pi 2b (of hoger natuurlijk) met een ultimate GPS hat geeft hier een nauwkeurigheid van ca. 1 microseconde.