Onderwerp: Publieke NTP-servers

In article <3ED0D982.2D500652@mobach.nl>, Fred Mobach <fred@mobach.nl> wrote:
>
>Waarom men geen NTP servers aanbiedt snap ik nog steeds niet, de kosten
>van zulke dozen hoeven echt niet zo hoog te liggen.

Erger nog, het is iets wat elk UNIX[1] systeem er probleemloos even bij
doet. Dus hebben we hier zo'n 300 NTP servers rondhangen die het niet
zouden merken als iemand van buiten daar om de 1024 seconden eens de
tijd aan vraagt. (Al zou ik liever zien dat ze ntp[123].few.vu.nl
gebruiken, die staan er morgen nog.)

Het probleem zijn al die ISP's die niet de moeite nemen om even een paar
NTP servers op te zetten voor de eigen gebruikers, zodat de druk op het
geringe aantal publieke servers zo hoog wordt dat die dingen bijna
instorten. (En het animo om publieke NTP servers op te zetten steeds
verder afneemt.)

[1] Op een paar W2K machines heb ik ook een NTP server geinstalleerd en
dat lijkt prima te werken, maar door mijn gebrekkige Windows kennis kan
ik niet zeggen of dat alleen maar zo lijkt of dat het echt betrouwbaar is.
--
Kees J. Bot, Systeemprogrammeur, Fac. Exacte Wetenschappen, Vrije Universiteit

Ruben van der Leij <ruben-news@nutz.nl> typed:

> As the load on the hosts supporting NTP primary (stratum 1) time
> service is heavy and always increasing, clients should avoid using
> the primary servers whenever possible.[..]

Zorgen deze servers met 'heavy load' ervoor dat mijn computerklok mogelijk
enkele secondes achter/voor loopt wanneer ik er gebruik van maak of is er in
de NTP-protocol een manier om deze afwijking te compenseren?

--
"Het kan me geen moer schelen wie je vader is, zolang ik hier zit te
vissen, loop jij niet over het water!"

D r . P r o z a c wrote in nl.internet.providers:
> > As the load on the hosts supporting NTP primary (stratum 1) time
> > service is heavy and always increasing, clients should avoid using
> > the primary servers whenever possible.[..]
>
> Zorgen deze servers met 'heavy load' ervoor dat mijn computerklok mogelijk
> enkele secondes achter/voor loopt wanneer ik er gebruik van maak of is er in
> de NTP-protocol een manier om deze afwijking te compenseren?

Je kunt het beste altijd een aantal servers gebruiken. ntps kiest dan
zelf de beste.

--
Kind regards,
Bas Zoetekouw ``Si l'on sait exactement ce que l'on va
faire, a quoi bon le faire?''
bas@o2w.nl Pablo Picasso

Kees J Bot wrote:
> Het probleem zijn al die ISP's die niet de moeite nemen om even een paar
> NTP servers op te zetten voor de eigen gebruikers

Yep. Thuis zit ik ook aan zo'n hommel gebakken. Dezelfde als jij. ;-)

> Op een paar W2K machines heb ik ook een NTP server geinstalleerd en dat
> lijkt prima te werken, maar door mijn gebrekkige Windows kennis kan ik
> niet zeggen of dat alleen maar zo lijkt of dat het echt betrouwbaar is.

Welke? Tardis draait vlekkeloos onder W2K.

-p

begin _quotations from: D r . P r o z a c <prozac@gmx.net>:

>Zorgen deze servers met 'heavy load' ervoor dat mijn computerklok mogelijk
>enkele secondes achter/voor loopt wanneer ik er gebruik van maak of is er in
>de NTP-protocol een manier om deze afwijking te compenseren?

Nee. *JIJ* zorgt er door misbruik te maken van Stratum-1 servers voor dat ze
in de toekomst niet publiek beschikbaar meer zullen zijn, en daarmee maak je
de beschikbaarheid van betrouwbare ntp-informatie problematischer.

De afwijkingen van een goed lopende stratum-1-klok liggen in de orde-grootte
van 0.000001 tot 0.0000001 seconde afwijking per jaar. Voor jouw pc-tje
thuis *VOLSTREKT* absurd overbodig.

--
Ruben van der Leij

http://www.blacklisted.nl/~ruben/why..._IE_or_OE.html

begin _quotations from: Bas Zoetekouw <bas+news@o2w.nl>:

>Je kunt het beste altijd een aantal servers gebruiken. ntps kiest dan
>zelf de beste.

Je kunt het beste eerst even www.ntp.org lezen voordat je blatante onzin
gaat roepen.

*JIJ* (en de rest van dit land) hebben meer dan genoeg aan *1* ntp-server
die dicht bij je in de buurt staat. Die van je provider, bijvoorbeeld. De
afwijkingen zijn zo microscopisch klein dat een tweede ntp-server je geen
enkel voordeel geeft. (Ntp berekent een afwijking voor je klok ('drift') en
past die toe op je klok. Na een maand is de afwijking van de klok van je PC
eigenlijk altijd in microseconden per maand uit te drukken of anders nog
minder.)

http://www.eecis.udel.edu/~mills/bib.html geeft je een lijstje van 111
boeken en publicaties om eens te lezen.

Onderstaande paragraaf mag je zien als een korte introductie in het
specifieke probleem wat ntp probeert te verhelpen:

(En de laatste zin is waarom je er zo naast zit. Tenzij je over een extreem
nauwkeurige klok en hele goeie verbindingen beschikt zijn de afwijkingen die
je systeem, je systeemklok en je netwerk introduceert van dusdanige aard dat
je eigenlijk alleen maar de dichtstbijzijnde klok gebruikt. De rest valt af.
Ze lastig vallen met gepoll is verspillen van hun tijd en moeite en gaat ten
koste van gebruikers die veel dichter bij die ntp-server zitten en door
gezooi uit Holland geen betrouwbare tijd krijgen. Wat je los daarvan met
een afwijking van microseconden moet gaat mij boven de pet. Al je
timestamps zijn in seconden dus een verschil van 0.49999 seconden zie
je al niet.)

Correctness Principles

Applications requiring reliable time synchronization such as air traffic
control must have confidence that the local clock is correct within some
bound relative to a given timescale such as UTC. There is a considerable
body of literature that studies these issues with respect to various failure
models such as fail-stop and Byzantine disagreement. While these models
inspire much confidence in a theoretical setting, most require multiple
message rounds for each measurement and would be impractical in a large
computer network such as the Internet. However, it can be shown that the
worst-case error in reading a remote server clock cannot exceed one-half the
roundtrip delay measured by the client. This is a valuable insight, since it
permits strong statements about the correctness of the timekeeping system.

In the Probabilistic Clock Synchronization (PCS) scheme devised by Cristian,
a maximum error tolerance is established in advance and time value samples
associated with roundtrip delays that exceed twice this value are discarded.
By the above argument, the remaining samples must represent time values
within the specified tolerance. As the tolerance is decreased, more samples
fail the test until a point where no samples survive. The tolerance can be
adjusted for the best compromise between the highest accuracy consistent
with acceptable sample survival rate.

In a scheme devised by Marzullo and exploited in NTP and DTSS, the
worst-case error determined for each server determines a correctness
interval. If each of a number of servers are in fact synchronized to a
common timescale, the actual time must be contained in the intersection of
their correctness intervals. If some intervals do not intersect, then the
clique containing the maximum number of intersections is assumed correct
truechimers and the others assumed incorrect falsetickers. Only the
truechimers are used to adjust the system clock.

System clock correctness principles require that clock readings must be
always monotonically increasing, so that no two successive clock readings
will be the same. As long as the reading latency exceeds the hardware
resolution, this behavior is guaranteed. With reading latencies dropping
below the microsecond in modern processors, the system clock in modern
operating systems runs in nanoseconds, rather than the microseconds used in
the original Unix kernel. With processor speeds exceeding 1 GHz, this
assumption may be in jeopardy.

Data Grooming Algorithms

By its very nature, clock synchronization is a continuous process, resulting
in a sequence of measurements with each of possibly several servers and
resulting in a clock adjustment. In some protocols, crafted algorithms are
used to improve the time and frequency estimates and refine the clock
adjustment. Algorithms described in the literature are based on trimmed-mean
and median filter methods. The clock filter algorithm used in NTP is based
on the above observation that the correctness interval depends on the
roundtrip delay. The algorithm accumulates offset/delay samples in a window
of several samples and selects the offset sample associated with the minimum
delay. In general, larger window sizes provide better estimates; however,
stability considerations limit the window size to about eight.

The same principle could be used when selecting the best subset of servers
and combining their offsets to determine the clock adjustment. However,
different servers often show different systematic offsets, so the best
statistic for the central tendency of the server population may not be
obvious. Various kinds of clustering algorithms have been found useful for
this purpose. The one used in NTP sorts the offsets by a quality metric,
then calculates the variance of all servers relative to each server
separately. The algorithm repeatedly discards the outlyer with the largest
variance until further discards will not improve the residual variance or
until a minimum number of servers remain. The final clock adjustment is
computed as a weighted average of the survivors.

--
Ruben van der Leij

http://www.blacklisted.nl/~ruben/why..._IE_or_OE.html

begin _quotations from: Ruben van der Leij <ruben-news@nutz.nl>:

>(En de laatste zin is waarom je er zo naast zit. Tenzij je over een extreem
>nauwkeurige klok en hele goeie verbindingen beschikt zijn de afwijkingen die
>je systeem, je systeemklok en je netwerk introduceert van dusdanige aard dat
>je eigenlijk alleen maar de dichtstbijzijnde klok gebruikt. De rest valt af.


Als illustratie even een dumpje van de stratum-2 server die ik beheer:

$ /usr/sbin/ntpq localhost
ntpq> assoc
ind assID status conf reach auth condition last_event cnt
================================================== =========
1 16460 90d4 yes yes none insane reachable 13
2 16461 9634 yes yes none sys.peer reachable 3
3 16462 9454 yes yes none synchr. reachable 5
4 16463 93b4 yes yes none outlyer reachable 11
5 16464 9414 yes yes none synchr. reachable 1
6 16465 9334 yes yes none outlyer reachable 3
7 16466 9394 yes yes none outlyer reachable 9
8 16467 8000 yes no
9 16468 93d4 yes yes none outlyer reachable 13
10 16469 9174 yes yes none falsetick reachable 7
11 16470 8000 yes no
12 16471 8000 yes no
13 16472 9374 yes yes none outlyer reachable 7
14 16473 8000 yes no
15 16474 9254 yes yes none eliminate reachable 5
16 16475 8063 yes no lost reach 6
17 16476 9234 yes yes none eliminate reachable 3
18 16477 9354 yes yes none outlyer reachable 5
19 16478 9254 yes yes none eliminate reachable 5
20 16479 9214 yes yes none eliminate reachable 1
21 16480 8000 yes no
22 16481 9374 yes yes none outlyer reachable 7

22 klokken. 1 peer, twee syncs. De rest is op grond van latency
geelimineerd, wijkt te veel af (outlyer), heeft last van jitter (falsetick)
of is 'insane'. Nog los van de 'gewone' niet vaak genoeg te bereiken
klokken. Van de 22 geconfigde peers zijn er wel 3 het veld op gegaan en
zitten er 4 op het spelersbankje. De rest mag douchen of thuisblijven.

--
Ruben van der Leij

http://www.blacklisted.nl/~ruben/why..._IE_or_OE.html

Ruben van der Leij <ruben-news@nutz.nl> typed:

> begin _quotations from: D r . P r o z a c <prozac@gmx.net>:
>
>> Zorgen deze servers met 'heavy load' ervoor dat mijn computerklok
>> mogelijk enkele secondes achter/voor loopt wanneer ik er gebruik van
>> maak of is er in de NTP-protocol een manier om deze afwijking te
>> compenseren?
>
> Nee. *JIJ* zorgt er door misbruik te maken van Stratum-1 servers voor
> dat ze in de toekomst niet publiek beschikbaar meer zullen zijn, en
> daarmee maak je de beschikbaarheid van betrouwbare ntp-informatie
> problematischer.

> De afwijkingen van een goed lopende stratum-1-klok liggen in de
> orde-grootte van 0.000001 tot 0.0000001 seconde afwijking per jaar.
> Voor jouw pc-tje thuis *VOLSTREKT* absurd overbodig.

Ik zou niet eens merken als mijn PC-klok 1 minuut verkeerd loopt, maar ik
was gewoon nieuwsgierig of de vertraging wordt gecompenseerd wanneer ik mijn
PC-klok synchroniseer met een trage (door heavy load?) NTP-server.
Ik zelf maak gebruik van de NTP-server van mijn eigen provider. Dat is toch
geen misbruikt? Deze NTP-server is tevens een POP3-server en reageert niet
al te snel, vandaar dat ik me afvroeg of deze traagheid wordt gecompenseerd
door de NTP-protocol.
--
"Het kan me geen moer schelen wie je vader is, zolang ik hier zit te
vissen, loop jij niet over het water!"

Ruben van der Leij wrote in nl.internet.providers:
> begin _quotations from: Bas Zoetekouw <bas+news@o2w.nl>:
>
> >Je kunt het beste altijd een aantal servers gebruiken. ntps kiest dan
> >zelf de beste.
>
> Je kunt het beste eerst even www.ntp.org lezen voordat je blatante onzin
> gaat roepen.
> *JIJ* (en de rest van dit land) hebben meer dan genoeg aan *1* ntp-server
> die dicht bij je in de buurt staat. Die van je provider, bijvoorbeeld. De
> afwijkingen zijn zo microscopisch klein dat een tweede ntp-server je geen
> enkel voordeel geeft. (Ntp berekent een afwijking voor je klok ('drift') en
> past die toe op je klok. Na een maand is de afwijking van de klok van je PC
> eigenlijk altijd in microseconden per maand uit te drukken of anders nog
> minder.)

OK, je hebt gelijk dat het voor thuis niet uitmaakt. Het is echter
wel degelijk zo dat ntp slim genoeg is om de beste server uit te
zoeken.

--
Kind regards,
Bas Zoetekouw ``Si l'on sait exactement ce que l'on va
faire, a quoi bon le faire?''
bas@o2w.nl Pablo Picasso

Ruben van der Leij wrote:
>
> begin _quotations from: Bas Zoetekouw <bas+news@o2w.nl>:
>
> >Je kunt het beste altijd een aantal servers gebruiken. ntps kiest dan
> >zelf de beste.
>
> Je kunt het beste eerst even www.ntp.org lezen voordat je blatante onzin
> gaat roepen.

<<zwaar geknipt in Rubens betoog>>

> *JIJ* (en de rest van dit land) hebben meer dan genoeg aan *1* ntp-server
> die dicht bij je in de buurt staat. Die van je provider, bijvoorbeeld.

Twee van je provider doet anders geen kwaad, zo'n configuratie gaat dan
jaaaren mee.

> (... Wat je los daarvan met
> een afwijking van microseconden moet gaat mij boven de pet. Al je
> timestamps zijn in seconden dus een verschil van 0.49999 seconden zie
> je al niet.)

Kleine aanvulling : bij logs wel, bij tcpdump niet. Waarbij zij
opgemerkt, dat ik de tijdmeting in tcpdump alleen van belang vind
relatief ten opzichte van gelijktijdige tcpdump uitvoer op andere
systemen. Reden, waarom ik al die systemen laat synchroniseren op een
ntp server in het lokale netwerk.
--
Fred Mobach - fred@mobach.nl - postmaster@mobach.nl
Systemhouse Mobach bv - The Netherlands - since 1976
website : http://fred.mobach.nl
There's nothing remarkable about it. All one has to do is hit the right
keys at the right time and the instrument plays itself. - J.S. Bach

"EL PIÑO" <elpino@isvervelend.be> schreef in bericht
news:5i71dvscf28eqdpjlt15g3v1d3oc710ku8@curry.zeda t.uni-berlin.de...
> >Het gaat niet om de provider via welke ik dit bericht post.
>
> Goh, weet je wat, dan zet je er voortaan bij om welke I(S)P het gaat, en
> dan kunnen wij je (als helpdesk ng) nog beter helpen..

De vraag was om publieke NTP-servers. Ik wil dan niet "de ntp-server van je
provider" als antwoord, waarbij mensen dan ook nog uit mijn headers zelf
conclusies gaan trekken die niet relevant zijn voor het beantwoorden van
mijn vraag.

Het enige juiste antwoord was: "zie de lijst op ntp.org"

Bm

"Mendel Mobach" <usenet@megabot.nl> schreef in bericht
news:slrnbd1eq2.51s.usenet@dolens.mobach.nl...
> De wet op behoud van ellende noopte
> Badmuts <badmutzREMOVE@THISwanadoo.nl>
> in nl.internet.providers tot het schrijven van:
> > Kryz wrote:
> >> On Sat, 24 May 2003 11:53:10 +0200, Piet Smeekens wrote:
> >>
> >>> Hè, Heikeneuker, denk jij eens aan jouw bijlagen?
> >>> c) Volgens mij bedoel je "heikneuter", maar goed
> >
> > Misschien heet z'n vriendin Heike, of heeft 'ie een spannende affaire
gehad
> > met een Duitse schone?
>
> Dat laatste wil ik wel erkennen.

Vertel! Alle ranzige details!

Bm
(heeft ze ook graag internationaal)

" D r . P r o z a c" <prozac@gmx.net> schreef in bericht
news:bau806$2tn9$1@nl-news.euro.net...
> Ik zou niet eens merken als mijn PC-klok 1 minuut verkeerd loopt, maar ik
> was gewoon nieuwsgierig of de vertraging wordt gecompenseerd wanneer ik
mijn
> PC-klok synchroniseer met een trage (door heavy load?) NTP-server.

Het protocol middelt zelf de vertraging uit, dus je klokkie gaat heus goed
lopen, ook bij een trage server.

Bm

In article <slrnbd54ch.je4.ruben-news@its.blacklisted.nl>, Ruben van der Leij wrote:
> begin _quotations from: Bas Zoetekouw <bas+news@o2w.nl>:
>
>>Je kunt het beste altijd een aantal servers gebruiken. ntps kiest dan
>>zelf de beste.
>
> Je kunt het beste eerst even www.ntp.org lezen voordat je blatante onzin
> gaat roepen.
>
> *JIJ* (en de rest van dit land) hebben meer dan genoeg aan *1* ntp-server
> die dicht bij je in de buurt staat.

Voordat je gaat schreeuwen, waarom niet even dit lezen:
http://www.ntp.org/ntpfaq/NTP-s-algo.htm#Q-NTP-ALGO

5.3.2. Why should I have more than one clock?
[...]

Wat voor mij vooral van belang was om meerdere klokken te nemen
was het argument dat het idee dat als ik een `gewoon' klokje van
mijn provider neem, dat het altijd kan gebeuren dat dat systeem
even down is, of zo. Dan maar liever een paar ntp-servers.

Dit ook omdat ik geen belangrijke stratum-1 servers wilde hebben
(die misschien meer te vertrouwen zijn), maar `gewone' servertjes.

Groetjes,
joostje

begin _quotations from: Bas Zoetekouw <bas+news@o2w.nl>:

>wel degelijk zo dat ntp slim genoeg is om de beste server uit te
>zoeken.

En allerlei servers die op grond van latency, jitter of lag afvallen wel
iedere paar minuten lastig valt. Zonder dat ze ooit zullen bijdragen aan de
nauwkeurigheid van je klok.

--
Ruben van der Leij

http://www.blacklisted.nl/~ruben/why..._IE_or_OE.html