NTP servers

[Maarten Carels]

Al lang heeft XS4ALL een aantal NTP servers, waar klanten hun server mee
kunnen tijdsychroniseren.
Die dienst was bij een aantal servers 'erbij' geschoven, voortschrijdend
inzicht geeft aan dat die keuze wat ongelukkig was.

We hebben al een flinke tijd andere NTP server actief, en ook de DNS
voor namen als ntp.xs4all.nl, ntp2.xs4all.nl, ntp3.xs4all.nl wijst naar
de nieuwe servers.

Binnenkort (1 juli) gaan we de ntp dienst op de oude ip's opheffen.

Mocht je nog de oude servers gebruiken (dat is dus als je de oude ip's
in je ntp config hebt staan) dan gaat het bij je stuk (oftewel je klok
gaat afwijken).

Daarom dus:
Gebruik liefst de namen:
ntp.xs4all.nl
ntp2.xs4all.nl
ntp3.xs4all.nl

Of, als je er 4 wil (met ip adressen erbij, allemaal .xs4all.nl):
ntp2-1 86400 IN A 194.109.6.2
ntp2-2 86400 IN A 194.109.6.22
ntp2-3 86400 IN A 194.109.9.2
ntp2-4 86400 IN A 194.109.9.42

Gebruik dus liefst de namen, al zullen de ip adressen niet meer
veranderen (is een 'service-ip', speciaal voor de dienst ntp toegekend).

Per 1 juli is het met de oude ip adressen (dat zijn 194.109.20.18,
194.109.20.19, 194.109.22.18 en 194.109.22.19) afgelopen.

--maarten

[Rob]

Maarten Carels <mca...@xs4all.nl> wrote:
>....

> Of, als je er 4 wil (met ip adressen erbij, allemaal .xs4all.nl):
> ntp2-1 86400 IN A 194.109.6.2
> ntp2-2 86400 IN A 194.109.6.22
> ntp2-3 86400 IN A 194.109.9.2
> ntp2-4 86400 IN A 194.109.9.42
>
> Gebruik dus liefst de namen, al zullen de ip adressen niet meer
> veranderen (is een 'service-ip', speciaal voor de dienst ntp toegekend).

De eerder vermelde IPv6 adressen blijven ook werken neem ik aan?

> Per 1 juli is het met de oude ip adressen (dat zijn 194.109.20.18,
> 194.109.20.19, 194.109.22.18 en 194.109.22.19) afgelopen.

Tja helaas is een probleem met NTP dat je op geen enkele manier
kunt communiceren met de klant, buiten dit soort newspostings dan.
Ga er maar vanuit dat het gebruik van die adressen gewoon onverminderd
doorgaat...

Maar goed, eventuele maatregelen om de service toch nog te verlenen of
om te proberen iets over te brengen door bepaalde gemanipuleerde info
terug te geven zijn neem ik aan al overwogen en gaan ook niks uithalen
uiteraard.

[Philip Homburg]

In article <slrnpgfvsu...@xs9.xs4all.nl>,

Rob <nom...@example.com> wrote:
>Tja helaas is een probleem met NTP dat je op geen enkele manier
>kunt communiceren met de klant, buiten dit soort newspostings dan.
>Ga er maar vanuit dat het gebruik van die adressen gewoon onverminderd
>doorgaat...

Dat ligt eraan in welke eeuw die klant leeft. RFC 5905 (juni 2010) beschrijft
de zogenaamde "Kiss-o'-Death" (sectie 7.4)

"a. For kiss codes DENY and RSTR, the client MUST demobilize any
" associations to that server and stop sending packets to that
" server;

--
We just programmed the computers to revive us when it was all over... they
were index linked to the [...] stock market prices you see, so that we'd
be revived when everybody else had rebuilt the economy enough to be able to
afford our rather expensive services again. -- Slartibartfast in THHGTTG

[Rob]

Philip Homburg <phi...@ue.aioy.eu> wrote:
> In article <slrnpgfvsu...@xs9.xs4all.nl>,
> Rob <nom...@example.com> wrote:
>>Tja helaas is een probleem met NTP dat je op geen enkele manier
>>kunt communiceren met de klant, buiten dit soort newspostings dan.
>>Ga er maar vanuit dat het gebruik van die adressen gewoon onverminderd
>>doorgaat...
>
> Dat ligt eraan in welke eeuw die klant leeft. RFC 5905 (juni 2010) beschrijft
> de zogenaamde "Kiss-o'-Death" (sectie 7.4)
>
> "a. For kiss codes DENY and RSTR, the client MUST demobilize any
> " associations to that server and stop sending packets to that
> " server;

De meeste NTP implementaties doen daar niets mee, en zeker niet iets
in de trant van het informeren van de operator. Bovendien is het
nooit persistent: je zou kunnen denken ik doe dat een maandje en dan
doe ik hem uit, maar alle clients die het wel implementeren doen dat
alleen voor de huidige instance dus na de volgende reboot gaan ze weer
gewoon aan de slag met die server.

Er bestaan zelfs implementaties die dergelijke replies beschouwen als
een reden om het meteen weer te proberen omdat het reply naar hun idee
invalid is en ze kennelijk denken dat je dat oplost door een nieuwe
query. Dat geldt ook voor het niet geven van antwoord trouwens: er
zijn clients die als je geen antwoord meer geeft gewoon een keer per
seconde ipv een keer per minuut gaan vragen.

[Alex Plantema]

Maarten Carels schreef:

> Al lang heeft XS4ALL een aantal NTP servers, waar klanten hun server
> mee kunnen tijdsychroniseren.
> Die dienst was bij een aantal servers 'erbij' geschoven,
> voortschrijdend inzicht geeft aan dat die keuze wat ongelukkig was.
>
> We hebben al een flinke tijd andere NTP server actief, en ook de DNS
> voor namen als ntp.xs4all.nl, ntp2.xs4all.nl, ntp3.xs4all.nl wijst
> naar de nieuwe servers.
>
> Binnenkort (1 juli) gaan we de ntp dienst op de oude ip's opheffen.

Zitten die Fritzboxen daar ook niet op? Ik kan zo gauw niet vinden waar je dat instelt bij de 7360.

--
Alex.

[Erik Baas]

Op 25-05-2018 om 18:34 schreef Alex Plantema:

>> We hebben al een flinke tijd andere NTP server actief, en ook de DNS
>> voor namen als ntp.xs4all.nl, ntp2.xs4all.nl, ntp3.xs4all.nl wijst
>> naar de nieuwe servers.

> Ik kan zo gauw niet vinden waar je dat instelt bij de 7360.

Home Network Overview -> Network Settings -> Time Synchronization

--
Erik.

[Chris Jacobs]

Op 25-5-2018 om 19:10 schreef Erik Baas:

Vergeet niet drie puntjes --> advanced view

[Rob]

Wat is tegenwoordig de default waarde als je met het XS4ALL profiel werkt?

[Chris Jacobs]

Op 25-5-2018 om 20:25 schreef Rob:

Ik heb de instelling nooit veranderd, en hij staat op 0.europe.pool.ntp.org

[Alex Plantema]

Erik Baas schreef:

O ja, goed verstopt. Bij mij staat 0.europe.pool.ntp.org,
in elk geval geen IP-adres. Dat is alleen nodig voor DNS-servers.

--
Alex.

[Rob]

Ah dat staat er nog steeds.... Beschamende zaak is dat.
AVM had een fabrikant pool moeten aanvragen (avm.pool.ntp.org) en XS4ALL
had in hun profiel ntp.xs4all.nl oid moeten laten opnemen.

Nu worden de routers gelijk gezet met de door vrijwilligers gerunde NTP
servers ipv met door de verkopers van de spullen en diensten betaalde
servers. En het is ook nog eens tegen de terms of service van pool.ntp.org.

[Roger]

On 2018/05/25 20:50, Rob wrote:
> Chris Jacobs <chris....@xs4all.nl> wrote:
>> Op 25-5-2018 om 20:25 schreef Rob:

>>> Wat is tegenwoordig de default waarde als je met het XS4ALL
>>> profiel werkt?
>>
>> Ik heb de instelling nooit veranderd, en hij staat op
>> 0.europe.pool.ntp.org
>
> Ah dat staat er nog steeds.... Beschamende zaak is dat.
> AVM had een fabrikant pool moeten aanvragen (avm.pool.ntp.org)

Dat was wel zo netjes geweest.

> en XS4ALL had in hun profiel ntp.xs4all.nl oid moeten laten
> opnemen.

Ik weet niet of NTP servers onderdeel zijn van een Fritz!OS
providerprofiel. Zou wel zo handig zijn.

> Nu worden de routers gelijk gezet met de door vrijwilligers
> gerunde NTP servers ipv met door de verkopers van de spullen
> en diensten betaalde servers.

Voor consumer grade internettoegang is dat goed genoeg mits
Fritz!OS kan overschakelen naar een andere server in de pool.
Gebruikt Fritz!OS eigenlijk meer dan één server uit een pool?
Ik heb geen idee...

> En het is ook nog eens tegen de terms of service van pool.ntp.org.

Dat lees ik hier nergens: http://www.pool.ntp.org/tos.html
Hier staat wel een 'Do not ...': http://www.pool.ntp.org/en/vendors.html

Maar principieel ben ik het met je eens.

Groeten,
-Roger

[Roger]

On 2018/05/25 20:44, Alex Plantema wrote:
> Erik Baas schreef:
>> Op 25-05-2018 om 18:34 schreef Alex Plantema:
>>>> We hebben al een flinke tijd andere NTP server actief, en ook de DNS
>>>> voor namen als ntp.xs4all.nl, ntp2.xs4all.nl, ntp3.xs4all.nl wijst
>>>> naar de nieuwe servers.
>>
>>> Ik kan zo gauw niet vinden waar je dat instelt bij de 7360.
>>
>> Home Network Overview -> Network Settings -> Time Synchronization
>
> O ja, goed verstopt.

Een van die settings die ik op een andere plek onder zou
brengen (de hostname is er ook zo eentje). Maar wie ben ik...

Groeten,
-Roger

[Dirk T. Verbeek]

Op 25-05-18 om 20:50 schreef Rob:

> Chris Jacobs <chris....@xs4all.nl> wrote:
>> Op 25-5-2018 om 20:25 schreef Rob:
>>> Chris Jacobs <chris....@xs4all.nl> wrote:
>>>> Op 25-5-2018 om 19:10 schreef Erik Baas:
>>>>> Op 25-05-2018 om 18:34 schreef Alex Plantema:
>>>>>>> We hebben al een flinke tijd andere NTP server actief, en ook de DNS
>>>>>>> voor namen als ntp.xs4all.nl, ntp2.xs4all.nl, ntp3.xs4all.nl wijst
>>>>>>> naar de nieuwe servers.
>>>>>
>>>>>> Ik kan zo gauw niet vinden waar je dat instelt bij de 7360.
>>>>>
>>>>> Home Network Overview -> Network Settings -> Time Synchronization
>>>>>
>>>> Vergeet niet drie puntjes --> advanced view
>>>
>>> Wat is tegenwoordig de default waarde als je met het XS4ALL profiel werkt?
>>>
>> Ik heb de instelling nooit veranderd, en hij staat op 0.europe.pool.ntp.org
>
> Ah dat staat er nog steeds.... Beschamende zaak is dat.
> AVM had een fabrikant pool moeten aanvragen (avm.pool.ntp.org) en XS4ALL
> had in hun profiel ntp.xs4all.nl oid moeten laten opnemen.

In mijn 7490 staat netjes ntp.xs4all.nl

[A. Dumas]

Dirk T. Verbeek <dver...@xs4all.nl> wrote:
> Op 25-05-18 om 20:50 schreef Rob:
>> Chris Jacobs <chris....@xs4all.nl> wrote:
>>> Ik heb de instelling nooit veranderd, en hij staat op 0.europe.pool.ntp.org
>>
>> Ah dat staat er nog steeds.... Beschamende zaak is dat.
>> AVM had een fabrikant pool moeten aanvragen (avm.pool.ntp.org) en XS4ALL
>> had in hun profiel ntp.xs4all.nl oid moeten laten opnemen.
>
> In mijn 7490 staat netjes ntp.xs4all.nl

Ik weet bijna zeker dat je dat dan ooit zelf hebt aangepast, ook al weet je
het niet meer :)

[A. Dumas]

Maarten Carels <mca...@xs4all.nl> wrote:
> ntp2-1 86400 IN A 194.109.6.2
> ntp2-2 86400 IN A 194.109.6.22
> ntp2-3 86400 IN A 194.109.9.2
> ntp2-4 86400 IN A 194.109.9.42

Jammer dat het niet .21 - .24 kon zijn.

[Dirk T. Verbeek]

Op 26-05-18 om 02:41 schreef A. Dumas:

Dat idee heb ik ook, een gat in mijn geheugen.

[Arnold]

On Fri, 25 May 2018 21:39:25 +0200, Roger wrote:
> On 2018/05/25 20:50, Rob wrote:
> > Chris Jacobs <chris....@xs4all.nl> wrote:
> >> Op 25-5-2018 om 20:25 schreef Rob:
> >>> Wat is tegenwoordig de default waarde als je met het XS4ALL profiel
> >>> werkt?
> >>
> >> Ik heb de instelling nooit veranderd, en hij staat op
> >> 0.europe.pool.ntp.org
> >
> > Ah dat staat er nog steeds.... Beschamende zaak is dat.
> > AVM had een fabrikant pool moeten aanvragen (avm.pool.ntp.org)
>
> Dat was wel zo netjes geweest.

> > Nu worden de routers gelijk gezet met de door vrijwilligers gerunde
> > NTP servers ipv met door de verkopers van de spullen en diensten
> > betaalde servers.
>
> Voor consumer grade internettoegang is dat goed genoeg mits Fritz!OS kan
> overschakelen naar een andere server in de pool.

Nee, dat is niet 'goed genoeg' voor de vrijwilligers die die NTP servers
runnen. Achter 0.europe.pool.ntp.org zitten slechts 1890 NTP servers.
Hoeveel miljoen Fritz-devices heeft AVM met deze setup verkocht?

Als je het aantal AVM-devices per EU NTP server uitrekent en dat zet
naast het aantal NAT-sessies dat een F!B-router aankan, dan zijn er veel
AVM-routers die dat absoluut niet aankunnen. Dát maakt het nog kwalijker
dat ze nooit een eigen pool hebben aangevraagd.

Deze vrijwilligers bieden hun diensten niet *gratis* aan aan commerciele
organisaties. Het is een sociaal project om nauwkeurige tijd gratis
beschikbaar te maken voor iedereen.

Stel dat Microsoft en Apple net zo zouden denken als AVM, dan was de NTP-
pool al lang verleden tijd. Die load is niet op te brengen door die paar
vrijwillige NTP-servers in de pool.

> Gebruikt Fritz!OS eigenlijk meer dan één server uit een pool?
> Ik heb geen idee...

Dat zou het probleem voor de vrijwilligers alleen maar groter maken.

> > En het is ook nog eens tegen de terms of service van pool.ntp.org.
>
> Dat lees ik hier nergens: http://www.pool.ntp.org/tos.html Hier staat
> wel een 'Do not ...': http://www.pool.ntp.org/en/vendors.html

Zie 2e alinea op de hoofdpagina en de links aan de linkerkant op _iedere_
pagina op http://www.pool.ntp.org/ (ook de pagina's in het Duits ;-) ).

Daarnaast heb ik AVM er jaaaren geleden persoonlijk op gewezen dat ze een
vendor pool moesten aanvragen. Zij kunnen zich er dus niet achter
verschuilen dat ze het niet hebben geweten...

> Maar principieel ben ik het met je eens.

Mooi :-)

Groeten, Arnold

[hja]

On 2018-05-25, Maarten Carels <mca...@xs4all.nl> wrote:
> Al lang heeft XS4ALL een aantal NTP servers, waar klanten hun server mee
> kunnen tijdsychroniseren.
> Die dienst was bij een aantal servers 'erbij' geschoven, voortschrijdend
> inzicht geeft aan dat die keuze wat ongelukkig was.
>
> We hebben al een flinke tijd andere NTP server actief, en ook de DNS
> voor namen als ntp.xs4all.nl, ntp2.xs4all.nl, ntp3.xs4all.nl wijst naar
> de nieuwe servers.
>
> Binnenkort (1 juli) gaan we de ntp dienst op de oude ip's opheffen.

Misschien een domme vraag, maar ik keek n.a.v. dit bericht even de
configuratie van de 7490 door.

Komt het omdat ik een test-versie gebruik of zijn alle 7490 ingesteld
op een "europese pool" (niet xs4all.nl)?

Overigens heb ik nu alles zo ingesteld dat 1 apparaat vanaf de xs4all
ntp-servers de tijd bijhoudt. De configuratiefoutjes zijn er nu uit.

Met vriendelijke groet,
Huub Reuver

[Philip Homburg]

In article <slrnpggc3f...@xs9.xs4all.nl>,

Rob <nom...@example.com> wrote:
>De meeste NTP implementaties doen daar niets mee, en zeker niet iets
>in de trant van het informeren van de operator. Bovendien is het
>nooit persistent: je zou kunnen denken ik doe dat een maandje en dan
>doe ik hem uit, maar alle clients die het wel implementeren doen dat
>alleen voor de huidige instance dus na de volgende reboot gaan ze weer
>gewoon aan de slag met die server.

Ja, daar is weinig aan te doen. Het gaat erom dat de operator geinformeerd is.
Als die dat verder negeert dan kan je hoogstens aan naming en shaming doen.

>Er bestaan zelfs implementaties die dergelijke replies beschouwen als
>een reden om het meteen weer te proberen omdat het reply naar hun idee
>invalid is en ze kennelijk denken dat je dat oplost door een nieuwe
>query. Dat geldt ook voor het niet geven van antwoord trouwens: er
>zijn clients die als je geen antwoord meer geeft gewoon een keer per
>seconde ipv een keer per minuut gaan vragen.

Als het xs4all klanten betreft dan zal het quarantaine netwerk
waarschijnlijk wel de nodige aandacht opleveren.

[Rob]

Philip Homburg <phi...@ue.aioy.eu> wrote:
> In article <slrnpggc3f...@xs9.xs4all.nl>,
> Rob <nom...@example.com> wrote:
>>De meeste NTP implementaties doen daar niets mee, en zeker niet iets
>>in de trant van het informeren van de operator. Bovendien is het
>>nooit persistent: je zou kunnen denken ik doe dat een maandje en dan
>>doe ik hem uit, maar alle clients die het wel implementeren doen dat
>>alleen voor de huidige instance dus na de volgende reboot gaan ze weer
>>gewoon aan de slag met die server.
>
> Ja, daar is weinig aan te doen. Het gaat erom dat de operator geinformeerd is.
> Als die dat verder negeert dan kan je hoogstens aan naming en shaming doen.

Helaas is het enige wat je als NTP server van de gebruiker weet het IP
adres waar het request vandaan komt. En dat kan zelfs een NAT router
zijn! Helaas staat er in het request geen contact info zoals een mail
adres waar je info heen kunt sturen mbt de service.
En mechanismen die er vroeger waren om bij een IP adres contact info
te vragen (whois) die worden ook steeds verder kapot gemaakt onder het
mom van de privacy bescherming.

>>Er bestaan zelfs implementaties die dergelijke replies beschouwen als
>>een reden om het meteen weer te proberen omdat het reply naar hun idee
>>invalid is en ze kennelijk denken dat je dat oplost door een nieuwe
>>query. Dat geldt ook voor het niet geven van antwoord trouwens: er
>>zijn clients die als je geen antwoord meer geeft gewoon een keer per
>>seconde ipv een keer per minuut gaan vragen.
>
> Als het xs4all klanten betreft dan zal het quarantaine netwerk
> waarschijnlijk wel de nodige aandacht opleveren.

Maar die NTP servers stonden voor iedereen open, ik weet zat plekken
waar die geconfigureerd stonden. Vooral binnen Nederland natuurlijk.
Dat krijg je als je als provider diensten aanbiedt die andere goedkope
prutsers niet eens kennen, laat staan hebben. Vaak is er dan door
hulpvaardige mensen (al dan niet bij de helpdesk maar in ieder geval
in gebruikersforums e.d.) doorverwezen naar die servers.

Afijn over een jaar of 10 zal het gebruik wel minder zijn.

[Rob]

Of het rebooten van de router onder "backup". Ze maken er een
puzzelritje van daar bij AVM!

[Roger]

Fritz!OS is in de loop der jaren nogal gegroeid waarbij er steeds
meer ballen in de menukerstboom werden gehangen. En dan wil er nog
wel eens een bal op een ongelukkige plek terecht komen. Tijd voor
een 'Generalüberholung'...

Groeten,
-Roger

[Roger]

On 2018/05/26 11:05, Arnold wrote:
> On Fri, 25 May 2018 21:39:25 +0200, Roger wrote:
>> On 2018/05/25 20:50, Rob wrote:
>> > Nu worden de routers gelijk gezet met de door vrijwilligers gerunde
>> > NTP servers ipv met door de verkopers van de spullen en diensten
>> > betaalde servers.
>>
>> Voor consumer grade internettoegang is dat goed genoeg mits Fritz!OS kan
>> overschakelen naar een andere server in de pool.
>
> Nee, dat is niet 'goed genoeg' voor de vrijwilligers die die NTP servers
> runnen. Achter 0.europe.pool.ntp.org zitten slechts 1890 NTP servers.

Goed punt. Ik had het alleen van de NTP client kant bekeken.

> Hoeveel miljoen Fritz-devices heeft AVM met deze setup verkocht?

In Duitsland maakt AVM o.a. een aantal routers voor de Telekom
en zijn ze ook huisleverancier van bv. 1&1. Het zal alleen daar
al om miljoenen devices gaan.

> Als je het aantal AVM-devices per EU NTP server uitrekent en dat
> zet naast het aantal NAT-sessies dat een F!B-router aankan, dan
> zijn er veel AVM-routers die dat absoluut niet aankunnen.

Dat hangt er van af hoe slim de NAT wordt gedaan. Maar het kan
een disaster waiting to happen zijn.

> Daarnaast heb ik AVM er jaaaren geleden persoonlijk op gewezen
> dat ze een vendor pool moesten aanvragen. Zij kunnen zich er dus
> niet achter verschuilen dat ze het niet hebben geweten...

Sommige Duitsers verschuilen zich daar al decennia lang achter ;)

Ik heb maar eens een mailtje gestuurd naar de beheerder van het
NTP Pool project (Ask Bjorn Hansen).

Groeten,
-Roger

[nobody]

Die kommt bald. Het is nog te bezien of je er vrolijk van wordt.

[Rob]

Roger <ro...@nomailplease.local> wrote:
> In Duitsland maakt AVM o.a. een aantal routers voor de Telekom
> en zijn ze ook huisleverancier van bv. 1&1. Het zal alleen daar
> al om miljoenen devices gaan.

Ja dat is het probleem. En AVM is niet eens de enige die dit doet.
Er is ook al eens een probleem met Turk Telekom geweest en ik dacht
dat dit om een ander merk ging.

Het is vaak nog erger omdat er meestal geen echte NTP implementatie
in dit soort spullen zit, maar SNTP (simple NTP) wat inhoudt dat er
zo eens per uur een request gedaan wordt (meestal incl DNS lookup)
en het resultaat wordt in de klok geramd. Dus ook het aantal DNS
requests is heel hoog (en dit komt allemaal bij een paar servers
terecht) en als je pech hebt is het maximaal dom geimplementeerd
door die requests bijv allemaal op het hele uur te doen ipv om het
uur na inschakelen van het ding. Er ontstaat daardoor een gigantische
request piek op het hele uur.

> > Als je het aantal AVM-devices per EU NTP server uitrekent en dat
> > zet naast het aantal NAT-sessies dat een F!B-router aankan, dan
> > zijn er veel AVM-routers die dat absoluut niet aankunnen.
>
> Dat hangt er van af hoe slim de NAT wordt gedaan. Maar het kan
> een disaster waiting to happen zijn.

Het is nu al zo dat het runnen van een NTP pool server achter een NAT
router eigenlijk niet meer kan. Je moet een direct bereikbaar IP
hebben en ALS er al NAT is dan moet het statisch zijn, terwijl de
meeste consumenten NAT routers in feite dynamische NAT hebben en in
het geval van zo'n "port mapping" maken ze per inkomende "sessie"
een nieuwe dynamische NAT rule aan. Dit gaat helemaal fout bij een
protocol als NTP en heel veel clients.

> Ik heb maar eens een mailtje gestuurd naar de beheerder van het
> NTP Pool project (Ask Bjorn Hansen).

Onnodig, hij weet heel goed hoe het zit.
En dat er niks aan te doen is.

[Rob]

Het is gewoon een gebrek van- en een algemeen probleem met- ieder
boomgestructureerd menu (en met andere boomgestructureerde indelingen
van ongestructureerde informatie, zoals directorystructuren.

[jjge]

Ik kwam dat destijds al tegen op de VAX onder VMS. Help files,
boomgestructureerd, en wat je zocht zat (achteraf volkomen logisch)
altijd net onder een andere tak van de boom. Gelukkig kon je de Help
file gewoon als textfile doorzoeken...

[richard lucassen]

On 26 May 2018 00:46:19 GMT

A. Dumas <alex...@dumas.fr.invalid> wrote:

> > ntp2-1 86400 IN A 194.109.6.2
> > ntp2-2 86400 IN A 194.109.6.22
> > ntp2-3 86400 IN A 194.109.9.2
> > ntp2-4 86400 IN A 194.109.9.42
>
> Jammer dat het niet .21 - .24 kon zijn.

Lijkt me niet verstandig om alles op 1 netwerksegment te laten
draaien...

--
richard lucassen
http://contact.xaq.nl/

[Miquel van Smoorenburg]

In article <20180527161112.b38b...@lucassen.org>,

richard lucassen <mailin...@lucassen.org> wrote:
>On 26 May 2018 00:46:19 GMT
>A. Dumas <alex...@dumas.fr.invalid> wrote:
>
>> > ntp2-1 86400 IN A 194.109.6.2
>> > ntp2-2 86400 IN A 194.109.6.22
>> > ntp2-3 86400 IN A 194.109.9.2
>> > ntp2-4 86400 IN A 194.109.9.42
>>
>> Jammer dat het niet .21 - .24 kon zijn.
>
>Lijkt me niet verstandig om alles op 1 netwerksegment te laten
>draaien...

Dat IP adressen opeenvolgend zijn hoeft helemaal niet te
betekenen dat ze in hetzelfde segment zitten, of zelfs dat
ze in hetzelfde datacenter staan.

De IP adressen hierboven zijn allemaal als hostroutes
gerouteerd in het netwerk, en op de servers zelf zijn
het aliases op de loopback interface.

Mike.

[Coen]

On 25-5-2018 12:51, Maarten Carels wrote:
> ntp2-4 86400 IN A 194.109.9.42

Die server doet het al 51 uur niet :)

$ ntpdate -q 194.109.9.42
server 194.109.9.42, stratum 0, offset 0.000000, delay 0.00000
30 May 13:53:42 ntpdate[10306]: no server suitable for synchronization found

chronyc> sources
210 Number of sources = 9
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
<knip>
^? ntp3.xs4all.nl 2 10 0 51h +26ms[ +538us] +/-
26ms
<knip>

gr,
Coen

[Rob]

Coen <newstr...@rosdorff.dyndns.org> wrote:
> On 25-5-2018 12:51, Maarten Carels wrote:
>> ntp2-4 86400 IN A 194.109.9.42
>
> Die server doet het al 51 uur niet :)

Die ligt er wel vaker uit, het is het zwakke broertje van die 4.

[Rob]

Aha kijk hij doet het weer!

[HH]

Op 25 May 2018 schreef Maarten Carels <mca...@xs4all.nl>:

> Al lang heeft XS4ALL een aantal NTP servers, waar klanten hun server mee
> kunnen tijdsychroniseren.

> --maarten

Gebruiken deze XS4ALL NTP servers het standard time protocol (UDP-poort
37)? Zodat ze met een programma als Neutron zouden moeten werken?

http://keir.net/neutron.html

[Rob]

Nee. Dat is OUD.

NTP servers gebruiken het NTP protocol. UDP poort 123.

Je hoeft geen programma te installeren als je met Windows werkt, het
zit er standaard in. Gewoon bij je tijdinstellingen een tijdserver
opgeven.

Bij andere systemen (of ook bij Windows als je het beter wilt doen dan
het standaard ding doet) een NTP programma installeren.

[A. Dumas]

On 25/05/2018 12:51, Maarten Carels wrote:
> ntp.xs4all.nl
> ntp2.xs4all.nl
> ntp3.xs4all.nl
>
> Of, als je er 4 wil (met ip adressen erbij, allemaal .xs4all.nl):

> ntp2-1 86400 IN A 194.109.6.2
> ntp2-2 86400 IN A 194.109.6.22
> ntp2-3 86400 IN A 194.109.9.2

> ntp2-4 86400 IN A 194.109.9.42

Het is allemaal 1-op-1, he? Geen aliassen of clusters/pools. Ik zie:

ntp = ntp2-1 = 194.109.6.2 = 2001:888:0:7::2
ntp2 = ntp2-2 = 194.109.6.22 = 2001:888:0:7::22
ntp2-3 = 194.109.9.2 = 2001:888:0:8::2
ntp3 = ntp2-4 = 194.109.9.42 = 2001:888:0:8::42

ntp1 en ntp4 bestaan niet. Kun je niet alsnog ntp3 aan ntp2-3 hangen, en
ntp4 aanmaken voor ntp2-4, en misschien ntp1 als alias voor ntp? Dat zou
veel ocd-stress schelen :)

Ik neem aan dat 99% van de hits op ntp komt. Zou het niet logisch zijn
om ntp de pool-naam te maken? Misschien ook niet, ik weet er niet zoveel
van.

[Rob]

Dat heb ik ook al een keer voorgesteld.
Logisch en handig zou zijn als ntp.xs4all.nl een DNS naam was die 4 IPv4
(en 4 IPv6) adressen retourneert, en ntp1 t/m ntp4 ieder de 4
afzonderlijke adressen in IPv4 en IPv6.
SNTP (en NTP met lage eisen) toepassingen kunnen dan ntp.xs4all.nl
gebruiken en er is automatische loadbalancing en een zekere redundantie.
Serieuze NTP clients kunnen ntp1 t/m ntp4 als servers opgeven.

Maar er is kennelijk een historische reden voor de namen, ooit gekozen
toen het NTP versie 2 was (net zoals bijvoorbeeld pop3.xs4all.nl voor
POP versie 3 was).

Echter het huidige protocol, wat die servers ook ondersteunen, is
versie 4 dus die 2 is er niet anders dan om verwarring te zaaien.

[HH]

Op 02 Jun 2018 schreef Rob <nom...@example.com>:

Bedankt voor de info!

[Miquel van Smoorenburg]

In article <slrnph4oc0...@xs9.xs4all.nl>,

Rob <nom...@example.com> wrote:
>Maar er is kennelijk een historische reden voor de namen, ooit gekozen
>toen het NTP versie 2 was (net zoals bijvoorbeeld pop3.xs4all.nl voor
>POP versie 3 was).

Die "2" komt uit "stratum 2", en is een implementatie detail.
Het idee was ooit om ook stratum1 servers te hebben, en die
zouden dan ntp1-{1,2,..} gaan heten. En gewoon ntp, ntp2 zouden
dan wijzen naar de "beste" servers.

Alleen ik denk dat bijna niemand dat meer weet, vandaar dat
dat door elkaar gehaald wordt.

Ik ben het met je eens wbt ntp + ntp1/2/3/4, veel beter.

Mike.

[HH]

Op Fri, 25 May 2018 schreef Maarten Carels <mca...@xs4all.nl>:

> Gebruik liefst de namen:
> ntp.xs4all.nl
> ntp2.xs4all.nl
> ntp3.xs4all.nl

Meinberg NTP loopt hier intussen 24 uur met bovenstaande XS4ALL servers op
een pc die time stamps met milliseconde-precisie moet produceren.

Met het volgende server-lijstje in ntp.conf...

ntp.xs4all.nl
ntp2.xs4all.nl
ntp3.xs4all.nl
0.nl.pool.ntp.org
2.de.pool.ntp.org

...kiest Meinberg als voorkeur-server steevast de enige stratum 1
(pool)server uit de lijst, in dit geval 0.nl.pool.ntp.org, die GPS-tijd
als referentie gebruikt:

remote refid st
===================================
-2001:888:0:7::2 193.67.79.202 2
+2001:888:0:7::2 131.188.3.220 2
+2001:888:0:8::4 193.67.79.202 2
*83.162.251.163 .GPS. 1
-2001:67c:1401:2 131.188.3.223 2

(st = stratum)

Voor zover ik tot nu toe heb kunnen zien, is het verschil in
offset-waarden tussen de stratum 1 pool en de XS4ALL servers <3 ms. De
nauwkeurigheid van de XS4ALL servers is dus prima in vergelijking met de
stratum 1 pool. Als je om een of andere reden wilt wilt forceren dat
Meinberg bij voorkeur de XS4ALL servers gebruikt, moet je de stratum 1
server(s) uit ntp.conf van Meinberg verwijderen.

[Rob]

Nou je kunt die er wel in laten en evengoed aangeven dat je die van
XS4ALL prefereert (met het statement prefer op de server regel) maar
er is inderdaad wel een neiging in die software om een lagere stratum
de voorkeur te geven zelfs al is de delay en jitter hoger.

Nou is in dit geval die 83.162.251.163 ook een XS4ALL gebruiker (een
van de vrijwilligers die een NTP server voor de pool beschikbaar maakt,
en die door de horken van AVM lekker gemakkelijk gebruikt worden om hun
routertjes gelijk te zetten zonder zelf wat te hoeven doen).
En die vrijwilliger heeft er kennelijk een GPS referentie aan hangen
(kost tegenwoordig vrijwel niks meer) en die heeft dus zeer waarschijnlijk
wel een goed lopende klok.

Het is niet zo dat een stratum 2 server per definitie slechter is dan
een stratum 1. Hij kan zelfs beter zijn omdat hij meerdere stratum 1
bronnen kan hebben en deze onderling kan vergelijken en middelen en
klaarblijkelijk fout lopende eruit kan halen.

Ik heb zelf een stratum-2 server in een datacenter (XS4ALL DC2) waar 8
eigen stratum-1 servers met GPS referentie aan hangen plus die 4 servers
van XS4ALL als check, en het verschil tussen de lokale tijd op die server
en die van XS4ALL is meestal rond de 0.5 ms. Dan zit je in het gebied
waar asymmetrie in de vertraging op de netwerkverbindingen een factor
gaat worden. (als je op een DSL verbinding zit dan is dat effect veel
sterker en krijg je die afwijkingen zoals 3ms die je daar schrijft)

[Coen]

On 3-6-2018 12:30, Rob wrote:
> Ik heb zelf een stratum-2 server in een datacenter (XS4ALL DC2) waar 8
> eigen stratum-1 servers met GPS referentie aan hangen plus die 4 servers
> van XS4ALL als check, en het verschil tussen de lokale tijd op die server
> en die van XS4ALL is meestal rond de 0.5 ms. Dan zit je in het gebied
> waar asymmetrie in de vertraging op de netwerkverbindingen een factor
> gaat worden. (als je op een DSL verbinding zit dan is dat effect veel
> sterker en krijg je die afwijkingen zoals 3ms die je daar schrijft)

Mijn Pi (1B+) met GPS shield lijkt ongeveer 0,3ms af te wijken van de
Xs4all stratum 2 servers:

210 Number of sources = 9
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================

#* KPPS 0 4 377 11 +247ns[ -230ns] +/- 244ns
^- ntp2-1.xs4all.net 2 10 377 783 +326us[ +329us] +/- 27ms
^- ntp2-2.xs4all.net 2 9 377 188 +412us[ +412us] +/- 36ms
^- ntp2-3.xs4all.nl 2 9 377 477 +353us[ +354us] +/- 36ms
^- ntp3.xs4all.nl 2 10 377 615 +313us[ +315us] +/- 39ms

En vier servers uit '2.debian.pool.ntp.org':

^- ntp1.edutel.nl 2 10 377 249 +1596us[+1597us] +/- 13ms
^- ntp4.bit.nl 1 10 377 522 +276us[ +277us] +/- 5627us
^- schnitzel.team 2 10 377 25m +478us[ +485us] +/- 9791us
^- dsl-083-247-002-080.s> 2 10 377 340 -761us[ -760us] +/- 38m

Mijn gateway server/router gebruikt die Pi dan weer als source ook met
de Xs4all servers als referentie:

ntpq> pe
remote refid st t when poll reach delay offset jitter
==============================================================================
*pc42.dhcp.linux .KPPS. 1 u 111 1024 377 0.563 0.142 0.035
-ntp.xs4all.nl 193.67.79.202 2 u 841 1024 377 8.461 0.336 0.087
+ntp2-2.xs4all.n 193.67.79.202 2 u 886 1024 337 8.700 -0.140 0.057
-ntp2-3.xs4all.n 131.188.3.220 2 u 979 1024 377 8.808 -0.340 0.148
+ntp2-4.xs4all.n 131.188.3.220 2 u 929 1024 377 8.500 -0.315 0.122

Hier dus een 4 a 5 ms verschil tussen de lokale str. 1 en remote str 2.

En dat alles op een redelijk goed draaiende en licht belaste vdsl2 lijn.
Als straks de 80Mbit cap er af gaat wordt het misschien wel weer iets
beter. Een Pi 2 of 3 zou misschien ook nog wel weer schelen.

Tijd is een leuk fenomeen om mee bezig te zijn en heeft een vrij grote
community die het ook niet los kunnen laten :)

gr,
Coen

[Miquel van Smoorenburg]

In article <slrnph7gqm...@xs9.xs4all.nl>,

Rob <nom...@example.com> wrote:
>Ik heb zelf een stratum-2 server in een datacenter (XS4ALL DC2) waar 8
>eigen stratum-1 servers met GPS referentie aan hangen plus die 4 servers
>van XS4ALL als check

Aha, maar die eigen stratum-1 servers hangen niet in het datacenter
neem ik aan? Het probleem met GPS in een datacenter is dat je de
satellieten niet ziet door het beton ... en apparatuur op het dak
plaatsen met bekabeling naar je racks wordt (vrijwel) nooit toegestaan.

Mike.

[Rob]

Coen <newstr...@rosdorff.dyndns.org> wrote:
> On 3-6-2018 12:30, Rob wrote:
>> Ik heb zelf een stratum-2 server in een datacenter (XS4ALL DC2) waar 8
>> eigen stratum-1 servers met GPS referentie aan hangen plus die 4 servers
>> van XS4ALL als check, en het verschil tussen de lokale tijd op die server
>> en die van XS4ALL is meestal rond de 0.5 ms. Dan zit je in het gebied
>> waar asymmetrie in de vertraging op de netwerkverbindingen een factor
>> gaat worden. (als je op een DSL verbinding zit dan is dat effect veel
>> sterker en krijg je die afwijkingen zoals 3ms die je daar schrijft)
>
> Mijn Pi (1B+) met GPS shield lijkt ongeveer 0,3ms af te wijken van de
> Xs4all stratum 2 servers:
>

> En dat alles op een redelijk goed draaiende en licht belaste vdsl2 lijn.

Ja met VDSL2 gaat het beter dan met oudere versies maar veel meer
verschil maakt het of je lijn in Fast of Interleaved mode staat.
Het kan voorkomen dat je in de ene richting Fast en de andere richting
Interleaved hebt en dan heb je een veel grotere offset.
(modem en dslam kiezen dit kennelijk op basis van storingsnivo etc)

Mijn eigen chrony systeem op VDSL2 geeft ook weinig verschil:

MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================

#* PPS 0 4 377 19 -75ns[ -125ns] +/- 203ns
#- DCF 0 6 377 2 +309us[ +309us] +/- 1000us
^- ntp2-1.xs4all.net 2 10 377 903 -115us[ +33us] +/- 42ms
^- ntp2-3.xs4all.nl 2 10 377 256 +140us[ +152us] +/- 46ms

(andere sources weggelaten)

[Rob]

Inderdaad die zitten door het land verspreid op een ander netwerk.
Dat dak daar moeten we nog steeds mee aan de slag... ik begreep dat
er wel wat mogelijk was maar er is nog niks van gekomen. Dat zal
ongetwijfeld met glas worden aangesloten, geen UTP natuurlijk.

Overigens is de huidige generatie GPS ontvangers niet meer zo kieskeurig
als ze dat vroeger waren, achter een (niet gecoat) raam dat niet op het
noorden is werkt het meestal ook goed. Bijv ergens in een vensterbank
in een kantoorgedeelte.

[HH]

Op 03 Jun 2018 schreef Rob <nom...@example.com>:

>> Voor zover ik tot nu toe heb kunnen zien, is het verschil in
>> offset-waarden tussen de stratum 1 pool en de XS4ALL servers <3 ms. De
>> nauwkeurigheid van de XS4ALL servers is dus prima in vergelijking met de
>> stratum 1 pool. Als je om een of andere reden wilt wilt forceren dat
>> Meinberg bij voorkeur de XS4ALL servers gebruikt, moet je de stratum 1
>> server(s) uit ntp.conf van Meinberg verwijderen.
>
> Nou je kunt die er wel in laten en evengoed aangeven dat je die van
> XS4ALL prefereert (met het statement prefer op de server regel) maar
> er is inderdaad wel een neiging in die software om een lagere stratum
> de voorkeur te geven zelfs al is de delay en jitter hoger.

Bedankt voor de tip over de optie "prefer". Die heb ik al die tijd over
het hoofd gezien.

Ik heb "prefer" zopas toegevoegd aan ntp2.xs4all.nl (die vertoont hier
telkens de laagste jitter).

Meinberg pakt nu ntp2.xs4all.nl ondanks de aanwezigheid van een stratum-1
server in de lijst:

remote refid st
===================================
+2001:888:0:7::2 193.67.79.202 2
*2001:888:0:7::2 131.188.3.220 2

+2001:888:0:8::4 193.67.79.202 2

+193.169.139.87 238.213.222.236 2
+2001:638:502:13 .DCF. 1

(Die stratum-1 server is uit de Duitse pool 2.de.pool.ntp.org)

[Erik]

Op 3-6-2018 om 14:24 schreef Miquel van Smoorenburg:

Daar hadden wij eigenlijk geen problemen mee, dat werd ons toegestaan.
Maar er was dan ook een dwingende reden om een stratum 1 klok te gebruiken.

Meerdere grote datacentra in Nederland en Europa.

Groet,
Erik