ntpd auf Dial-In-Maschine.

Mon Mar 13 18:35:31 CET 2006

On Mon, Mar 13, 2006 at 05:43:38PM +0100, Arnd Behring wrote:
> On Mon, 13 Mar 2006 17:35:54 +0100
> Florian Lohoff <flo at rfc822.org> wrote:
> > Nebenbei bemerkt sollte man von NTP ueber ADSL leitungen eh nicht
> > alzuviel erwarten. NTP funktioniert nur mit der richtigen praezision
> > wenn die laufzeiten in beide richtungen identisch sind. Was im falle von
> > ADSL mitnichten der fall ist.
> 
> Mal so aus reiner Neugier: Wie groß ist denn dieser Unterschied in
> etwa? Und womit hängt der zusammen?

Der NTP ermittelt mindestens mal 3 werte. RTT (Round Trip Time), drift
(Abweichung der Ganggenauigkeit zur Referenzuhr) und Offset
(Zeitdifferenz zur Referenzuhr).

Die RTT ist wichtig um den offset korrigieren zu koennen. D.h. Wenn
meine lokale Uhr die Exakte zeit hat hat sie trotzdem einen offset zur
remote uhr weil ja das paket eine laufzeit unterwegs ist. Diese Laufzeit
muss ich runterrechnen um die uhr exakt korrigieren zu koennen.

Der Offset bestimmt die absolute genauigkeit der Uhr d.h. inwiefern sie
absolut vom Zeitnormal abweicht.

Der drift oder auch Gangenauigkeit bestimmt die genauigkeit der Uhr in bezug auf die
geschwindigkeit. Der drift drueckt die geschwindigkeitsdifferenz der
lokalen Uhr zum Zeitnormal aus.

Die einzige moeglichkeit des NTPs diese Werte zu ermitteln ist ueber die
zeit immer wieder pakete zwischem lokalem und referenzuhr Ping-Pong
spielen zu lassen. D.h. lokale uhrueit in ein paket losschicken -
referenzuhr pakt auch eine zeit rein und schickts zurueck. 

Dann habe ich die zeiten a b und c. c-a ist die RTT und (c-a)/2 ist die
Laufzeitkorrektur. Aehnliches gilt fuer den Offset d.h. b+(c-a)/2 ist
demnach dann die uhrzeit die meine Uhr lokal bei eintreffen des paketes
haben sollte demnach die differenz zu c mein offset.

Das ganze ist jetzt stark vereinfacht. In wirklichkeit steckt da viel
mittelei ueber die zeit drin - Gangenauigkeit geht ueber einen
angenommenen drift der dann nach jeder messung der realitaet angepasst
wird und so ueber die zeit immer genauer wird.

flo at pobox:~$ ntpq
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*ntp0.mediaways. .GPS.            1 u  158 1024  377   81.130  -10.799  24.621
+ntp1.mediaways. .GPS.            1 u  790 1024  377   81.210   -7.862  37.661

st -> Stratum - Stratum 1 server sind direkte referenzserver. D.h. der
	Stratumcount gibt die Anzahl der Hops von der Referenzuhr an.
when -> gibt die anzahl der sekunden bis zum naechsten poll an.
poll ->ist der interval in dem gepollt wird.
reach -> ist ein oktal wert - hier 11111111 d.h. die letzten 8 male war die
	referenzuhr erreichbar. 
delay -> ist die RTT, offset der offset zur uhr 
jitter -> varianz des offsets

Jetzt das ADSL Problem. Bei ADSL sind die laufzeiten zwischen hin und rueckweg
signifikant unterschiedlich durch die unterschiedlichen Bandbreiten bedingt.
Dadurch ist der delay aka RTT zwar korrekt - der delay der aber 1/2 RTT sein sollte
nicht. Dadurch ist zwar die gangenauigkeit der lokalen uhr (drift) in ordnung
aber die absolute distanz nicht. Sie weicht ab um die differenz zwischen 1/2 RTT zu 
differenz zwischen hin und rueckweg. Das koennen durchaus 20-40ms sein.

Das ganze ist fuer dein Heimanwender wohlmoeglich nicht kritisch allerdings fuer 
den kommerziellen einsatz wie bei uns in der Firma inakzeptabel. Bei uns haengen 
an den NTP Daten abrechnungsrelevante Datensaetze und wer bezahlt schon gerne mehr
als genutzt. 

Um das ganze zu verdeutlichen - Hier ein ntpq output einer der referenzuhren
die ich in der Firma betreue:

cron:~# ntpq
ntpq> rv
status=04f4 leap_none, sync_uhf_clock, 15 events, event_peer/strat_chg,
version="ntpd 4.1.0 Mon Mar 25 23:37:17 UTC 2002 (1)", processor="i686",
system="Linux2.2.18", leap=00, stratum=1, precision=-17,
rootdelay=0.000, rootdispersion=2.679, peer=31268, refid=GPS,
reftime=c7c02a09.0646e08f  Mon, Mar 13 2006 17:27:37.024, poll=6,
clock=c7c02a10.b19c9d5a  Mon, Mar 13 2006 17:27:44.693, state=4,
offset=-0.250, frequency=92.980, jitter=1.129, stability=0.040
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*GENERIC(0)      .GPS.            0 l    8   64  377    0.000   -0.250   0.720
+ntp1.mediaways. .GPS.            1 u   15   64  376    0.097   -0.137   0.187
+ptbtime2.ptb.de .PTB.            1 u   13   64  377   15.287    0.589   3.686

D.h. die beiden peer systeme haben einen offset von 0.1 bzw 0.2ms
zur Normalzeit. Zu der oeffentlichen Referenzuhr des PTB (Phyikalisch
Technische Bundesanstalt) immerhin noch 0.5ms was vermutlich auch durch
den Delay von 15ms verursacht ist. Die Uhren des PTB sind bei uns allerdings nur
als Backup eingetragen falls jemand beim Schneeschueppen auf dem Dach die
GPS Antenne abreisst.

D.h. mein Heimsystem hinter der ADSL strecke hat einen bekannten offset
von 7-10ms plus einen unbekannten offset wie oben beschrieben. Dazu
einen jitter von 24 bis 37ms.

Wer es jetzt Perves mag kann ja mal den "unbekannten" offset errechnen 
der verursacht wird durch die serielle anbindung des GPS empfaengers. D.h. 
ich habe ja einen delay den die serielle message auf den 2 draehten zuruecklegt
(Soetwas wird im ueberigen in der config fest verdrahtet und damit korrigiert)

# GPS Clock
server 127.127.8.0 mode 7 prefer
fudge 127.127.8.0 time1 0.0042

Flo
-- 
Florian Lohoff                  flo at rfc822.org             +49-171-2280134
                        Heisenberg may have been here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lug-owl.de/pipermail/linux/attachments/20060313/85ff97fc/attachment.sig>