Vorlesung. Rechnernetze II Teil 13. Sommersemester 2004

Transkript

1 Vorlesung Rechnernetze II Teil 13 Sommersemester 2004 Christian Grimm Fachgebiet Distributed Virtual Reality (DVR) Lehrgebiet Rechnernetze C. Grimm 14. Juli 2004

2 Übersicht Motivation und Beispiele Zeiteinheit und Zeitsysteme Grundbegriffe der Zeitmessung Genauigkeit einer Uhr Offset zwischen zwei Uhren Uhren in Rechnern Kompensieren von driftenden Uhren Disziplinierung einer lokalen Systemuhr Synchronisation von Uhren in verteilten Systemen Algorithmus von Cristian Berkeley Algorithmus Lamport Algorithmus logische Zeit Network Time Protocol C. Grimm 14. Juli 2004 Folie 2

3 Motivation Frage Wofür synchronisierte Uhren in Rechnernetzen? mögliche Szenarien, in denen nicht synchronisierte Uhren Probleme bereiten Timestamps von Dateien in verteilten Dateisystemen verteilte Entwicklung von Software Archivierung und Backups Nachvollziehbarkeit von Angriffsversuchen zeitliche Ordnung verschiedener Log-Dateien Performance-Messungen in Netzwerken Einwege-Messungen zur Bestimmung von Delay und Jitter Caching im WWW Timestamp Last-Modified: wird vom Server gesetzt und vom Client ausgewertet Timestamp Expires: wird vom Server gesetzt und vom Client ausgewertet C. Grimm 14. Juli 2004 Folie 3

4 Beispiel: Messung des Offset von WWW-Servern Vorgehen Abruf der Homepages von WWW-Servern durch HEAD-Request Berechnung des Offset Referenzzeit des WWW-Servers aus Zeile Time: im Header der HTTP-Response Referenzzeit Zeit auf Messrechner ist die Mitte zwischen Begin und Ende der Messung Offset ist die Differenz der Referenzzeiten Anzahl WWW-Server [%] min +2 min min -10 min Offset [h] C. Grimm 14. Juli 2004 Folie 4

5 Beispiel: Aufruf von make in verteilter Umgebung Ablauf 1. Erstellen einer Quelldatei (hier test.c) auf Computer 1 2. Starten von make auf Computer 2, Ergebnis ist die Objektdatei test.o 3. Ändern von test.c 4. Starten von make auf Computer 2 make vergleicht Timestamp von test.c (26) mit dem von test.o (28) keine neue Übersetzung von test.c, da neuerer Timestamp von test.o Computer 2 (Compiler) lokale Zeit auf Computer 1 Computer 1 (Editor) lokale Zeit auf Computer 2 C. Grimm 14. Juli 2004 Folie 5

6 Definition der Zeiteinheit Sekunde die Sekunde ist die Basiseinheit der Zeit im Internationalen Einheitensystem (SI) Definition der Sekunde bis 1956 die Sekunde ist der Teil des mittleren Sonnentages diese Definition ist jedoch nicht konstant vor ca. 400 Millionen Jahren hatte das Jahr noch 400 Tage, weiterhin gibt es Schwankungen in der Rotationsgeschwindigkeit der Erde (relativ um mehrere 10-8 s) Definition der Sekunde von die Sekunde ist 1/ ,9747 des tropischen Jahres von 1900 diese Ephemeridensekunde ist ca s kürzer als die heutige Weltzeitsekunde Definition der Sekunde ab 1967 durch das Bureau International de L Heure (BIH) Die Sekunde ist das fache der Periodendauer der dem Übergang zwischen den beiden Hyperfeinstrukturniveaus des Grundzustandes des Atoms 133 Cs entsprechenden Strahlung. C. Grimm 14. Juli 2004 Folie 6

7 Zeitsysteme GMT: Zeit auf dem Null-Meridian davon abgeleitet: 24 Zeitzonen ca. alle 15, mit jeweils 1h Differenz nach politischen oder geographischen Grenzen TAI: Temps Atomique International basiert auf Definition der Sekunde vom BIH ein TAI-Tag ist das Mittel eines Tages von ca. 250 Cäsium-133 Uhren weltweit korrespondiert nicht mit astronomischen Gegebenheiten ca. 3 ms kürzer als ein Sonnentag, daher unbrauchbar für das öffentliche Leben UT: abgeleitetet aus astronomischer Sternzeit UT1 zusätzlich Korrektur der Polschwankungen Bedeutung: mittlere Sonnenzeit am Meridian durch Greenwich UTC: Universal Time Coordinated basiert auf TAI, d. h. dieselbe Skala bei Differenz von 900 ms zu UT1 werden Schaltsekunden eingefügt Festlegung durch den International Earth Rotation Service ( C. Grimm 14. Juli 2004 Folie 7

8 Schaltsekunden Problem UT1-Sekunden sind länger als TAI-Sekunden Zitat aus NTP FAQ Unfortunately the earth s rotation is not very much impressed by the definition of the UTC second. Lösung Einfügen von Schaltsekunden in UTC bei einer Differenz von mehr als 900 ms Skalen zwischen UT1 und UTC werden abgeglichen TAI t UT t UTC t Einfügen einer Schaltsekunde C. Grimm 14. Juli 2004 Folie 8

9 Zeitmessung mit Atomuhren aktuell in Deutschland Cäsiumuhren CS1-4 der PTB, Abweichung 1, Cäsiumfontäne CSF1, Abweichung in USA geplant Cäsiumfontäne NIST-F1, Abweichung PARCS (Primary Atomic Reference Clock in Space) auf ISS geplant für 2008 höhere Genauigkeit aufgrund der Mikrogravitation C. Grimm 14. Juli 2004 Folie 9

10 Grundlagen zur Zeitmessung Begriffe Zeitpunkt Zeitspanne Oszillator Uhr bezeichnet einen Punkt auf der Zeitskala, kann zur Ordnung von Ereignissen herangezogen werden Differenz zwischen zwei Zeitpunkten Generator, der mit vorgegebener Frequenz schwingt Gerät zur Zeitmessung, erlaubt das Messen von Zeitdifferenzen, mit Bezugspunkt auch die Angabe von Zeitpunkten Oszillator Zähler Zeitmessung Genauigkeit (acccuracy) Präzision (precision) Stabilität (stability) Offset (offset) Drift (drift) Abweichung einer Uhr von der Referenzzeit Grad der Auflösung der Uhrzeit Maß für Frequenzschwankungen einer Uhr Zeitdifferenz zwischen zwei Uhren Frequenzabweichung zwischen zwei Uhren C. Grimm 14. Juli 2004 Folie 10

11 Genauigkeit einer Uhr Darstellung in einem Zeit-Diagramm t Referenzzeit, z. B. UTC C p (t) Wert der Uhr p zum Zeitpunkt t ρ maximal tolerierbare Abweichung (auch maximale Abweich- oder Drift-Rate) ideale Uhr C i (t) ideale Präzision ideale Stabilität d. h. kein Offset dc C p (t) = t p,t oder = 1 dt C(t) schnell schlechte Genauigkeit, gute Stabilität C 1 (t) perfekt ideale Genauigkeit, ideale Stabilität C i (t) C 3 (t) gute Genauigkeit, schlechte Stabilität reale Uhren C 1 (t), C 2 (t) und C 3 (t) schwankende Präzision schwankende Stabilität d. h. schwankender Offset zu C i (t) dc 1 ρ 1+ ρ dt Offset langsam C 2 (t) schlechte Genauigkeit, gute Stabilität t C. Grimm 14. Juli 2004 Folie 11

12 Offset zwischen zwei Uhren Frage nach welcher Zeit t müssen zwei Uhren C 1 (t) und C 2 (t) synchronisiert werden, damit ihre gegenseitige Abweichung (Offset) nicht den Wert δ übersteigt? Ansatz für Lösung auf beiden Uhren gleiche Drift-Rate ρ d. h. Abweichung gegenüber idealer Uhr ist symmetrisch maximale Abweichung darf δ betragen d. h. maximale Abweichung gegenüber idealer Uhr darf jeweils δ/2 betragen gesucht ist Zeitpunkt t d. h. nach t müssen Uhren erneut synchronisiert werden C(t) C 1 (t)=(1+ρ) t δ 1 δ 2 C i (t)=t C 2 (t)=(1 ρ) t aus Diagramm mit δ 1 (t) = C 1 (t) C i (t) = (1+ρ) t t und δ 2 (t) = C i (t) C 2 (t) = t (1 ρ) t folgt δ max (t) = δ 1 (t) + δ 2 (t) = 2 ρ t t= δ / ( 2 ρ) t C. Grimm 14. Juli 2004 Folie 12

13 Uhren in Rechnern einfachste Realisierung Uhr besteht aus Quarzoszillator, Zählregister, Initialisierungsregister Zähler wird mit Initialisierungsregister geladen und danach inkrementiert beim Überlauf bzw. Nulldurchgang des Zählers erfolgt ein CPU-Interrupt erneutes Laden des Initialisierungsregisters und Inkrementieren des Zählers usw. CPU zählt Interrupts und kann so Zeit ermitteln Anmerkungen mit dem Initialisierungsregister kann die Interrupt-Frequenz vorgegeben werden übliche Interrupt-Frequenz liegen bei 50 ms, z. B. PC: 54,95 ms (18,2 Hz) interne Darstellung der Zeit in Rechnern am Beispiel UNIX Rechner zählen Sekunden seit dem 1. Januar 1970 (Unix-Zeit) für die meisten Operationen werden 32-Bit Werte verwendet erlaubt Berechnung der Zeit bis zum Jahr 2038 erlaubt Berechnung von Zeitdifferenzen von max. 68 Jahren die Darstellung hh:mm:ss ist lediglich eine nutzerfreundliche Darstellung der UNIX-Zeit Funktionen zur Umrechnung in dieses Format z. B. durch timezone-bibliothek C. Grimm 14. Juli 2004 Folie 13

14 Uhren in Rechnern Genauigkeit und Präzision hängen vom Betriebssystem ab Betriebssystem: Implementierung des Schedulers, Prioritätsverteilung der Interrupts Fehlerquelle: Interrupt-Verluste, d.h. Fehler beim Zählen der Interrupts die Stabilität hängt von der Hardware-Uhr ab Fehlerquelle: Drift und Stabilität der Oszillatorfrequenz Frage Auf welche Zeitzone sollten Hardware-Uhren gestellt werden? Antwort zwei Möglichkeiten: lokale Zeit oder UTC es wird empfohlen wird, die Hardware-Uhr auf UTC zu stellen Umrechnung in lokale oder andere Zeitzonen erfolgt durch timezone-bibliothek des Betriebssystems C. Grimm 14. Juli 2004 Folie 14

15 Kompensieren von driftenden Uhren möglicher Ansatz periodisches Setzen der Uhr auf die Referenzzeit kein (größeres) Problem, wenn die Uhr nachgeht großes Problem, wenn die Uhr vorgeht (s. u.) nicht geeignet für Anwendungen, die auf hochgenaue Uhren angewiesen sind z. B. Einwege-Messungen in Netzwerken Frage Wo liegt das Problem, wenn die Uhr vorgeht? Antwort eine vorgehende Uhr wird zurück gesetzt mehrfaches Auftreten einer Zeitmarke möglich d. h. Monotonie der Zeit wird verletzt die zeitlich korrekte Ordnung von Nachrichten (z. B. syslog) ist nicht mehr sichergestellt Lösung Uhrenfrequenz erhöhen oder verlangsamen, bis die Referenzzeit erreicht ist C. Grimm 14. Juli 2004 Folie 15

16 Kompensieren von driftenden Uhren in Linux Kernelvariablen HZ: Vorbelegung mit dem Wert 100 tick: Vorbelegung mit dem Wert ( HZ/2) / HZ ergibt also mit HZ=100 tick=10,005 ms tickadj: Vorbelegung mit dem Wert 5 (5 us) Interrupt-Frequenz beträgt 100 Hz bei jedem Interrupt wird die Uhr um den Wert tick erhöht angleichen der Zeit durch Frequenzveränderung möglich (schneller/langsamer) Realisierung durch Funktion tickadj () Interrupt der Uhr hat nicht die höchste Priorität Verlust von Interrupts ist möglich d. h. Uhr geht nach Verlust eines Interrupts nach API settimeofday (): Setzen der internen Uhr, Verletzung der Monotonie adjtimex (): Angleichen der Uhr an die korrekte Zeit ohne die Monotonie zu verletzen C. Grimm 14. Juli 2004 Folie 16

17 Kompensieren von driftenden Uhren Uhren werden durch Setzen der Zeit oder variieren der Frequenz angepasst normal arbeitende Systemuhr tick t Verletzung der Monotonie durch Setzen der Systemuhr mit settimeofday () settimeofday () tick t Erhaltung der Monotonie durch Variieren der Frequenz mit adjtimex () adjtimex () tick tick tickadj tick+tickadj t C. Grimm 14. Juli 2004 Folie 17

18 Disziplinierung einer lokalen Systemuhr in Linux hochgenaue DCF77- und GPS-Empfänger liefern Zeittelegramm mit vollständiger Zeitinformation zusätzlich hochgenaue 1-pulse-per-second (1PPS) Signale 1PPS-Signale werden durch Rechner ausgewertet und zur Disziplinierung der Systemuhr eingesetzt Linux mit Nano-Kernel Patch gleiche Funktionalität zur Uhrendisziplinierung wie NTP, aber auf Kernel-Ebene stellt die PPS-API nach RFC 2783 bereit erhöht die Auflösung der Systemuhr auf 1 ns (Zeit) und 0,001 PPM (Frequenz) Dokumentation des PPS-Kit für Linux Source: ftp://ftp.de.kernel.org/pub/linux/daemons/ntp/pps nach Patchen des Kernels Datei kernel-time.txt in /usr/src/linux/documentation C. Grimm 14. Juli 2004 Folie 18

19 Einschwingvorgang der Systemzeit auf DCF-Peer C. Grimm 14. Juli 2004 Folie 19

20 Einschwingvorgang der Systemzeit auf PPS-Peer C. Grimm 14. Juli 2004 Folie 20

21 Einschwingvorgang der Systemzeit auf PPS-Peer C. Grimm 14. Juli 2004 Folie 21

22 Synchronisierung von Uhren in verteilten Systemen Probleme durch IP-Netz nicht deterministische Laufzeiten von Paketen in IP-Netzen durch variable Verzögerungen in Queues von Routern und Switches durch asymmetrisches Routing Paketverluste durch Überläufe in Queues oder Bitfehler Probleme durch Rechner Uhrenfrequenz vorgegeben durch Quarzoszillator bei zu hoher Frequenz geht die Uhr vor, bei zu niedriger nach Frequenz abhängig von Umgebungstemperatur keine beliebig hohe Auflösung bei der Ermittlung der Systemzeit bei hoher Rechnerlast können Interrupts von der Systemuhr verloren gehen Probleme durch Ort Rechner stehen evtl. in verschiedenen Zeitzonen C. Grimm 14. Juli 2004 Folie 22

23 Synchronisierung von Uhren in Rechnernetzen Problem / Aufgabe synchronisiere Systemzeit eines Clients gegenüber einem Server mit einer genauen Uhr einfachster Fall sende ein Paket an diesen Server (Timeserver) und bitte um die aktuelle Uhrzeit der Timeserver antwortet mit der aktuellen Zeit der Client stellt (settime ()) oder regelt (adjtimex ()) Uhr auf die empfangene Zeit Request Time Response 12:54: Client Server Bewertung einfaches Verfahren unpräzise durch Nichtbeachtung der Verarbeitungsdauer im Server durch Nichtbeachtung der Verzögerung bei der Übertragung C. Grimm 14. Juli 2004 Folie 23

24 Algorithmus von Cristian Eigenschaften dezentraler Algorithmus passiver Server Server hat nicht notwendigerweise eine mit einem Zeitnormal abgeglichene Uhr Ziel ist die Synchronisation der Systemzeit des Client T C auf die des Servers T S Fehler durch Übertragungsdauer von Request und Reply wird berücksichtigt Ansatz Kompensation der Übertragungsdauer (entspricht RTT) durch Berücksichtigung von Sendezeit Request T 0 Anmerkung. RTT enthält hier Verarbeitungszeit auf dem Server! Empfangszeit Reply T 1 Annahme: Übertragungsdauer für Request und Reply sind symmetrisch Server T S t Request Reply enthält T S Client T 0 T 1 T 1 T0 2 T1 T0 TC = TS + 2 t C. Grimm 14. Juli 2004 Folie 24

25 Algorithmus von Cristian Übertragungsdauer von Request und Reply sind selten symmetrisch und minimal ideal: d req = d rep = d r real: d req d rep Server T1 T = 2 0 TS T S T x t Fehler Client T 0 T T 1 T 1 T0 0 T 1 2 t d r T 1 T 0 2 d r d r d req T 1 T 0 d req d rep d rep Abschätzung des Fehlers zur Berechnung des Fehlers wird eine minimale Übertragungsdauer d min angenommen zum Zeitpunkt T 1 liegt die aktuelle Zeit auf dem Server T x im Bereich [T S + d min, T S + RTT d min ] Server hat T S frühestens vor der Zeit RTT d min gesetzt Server hat T S spätestens vor der Zeit d min gesetzt daraus folgt die Abschätzung des Fehlers zu ± RTT / 2 d min = ± (T 1 T 0 ) / 2 d min C. Grimm 14. Juli 2004 Folie 25

26 Algorithmus von Cristian Anmerkungen Reduzierung des Fehlers ist durch mehrmalige Wiederholung der Übertragung möglich einer der Vorgänge könnte nahe an der RTT min gewesen sein aus RTT min folgt d min = RTT min / 2 der Fehler durch die Verarbeitungsdauer im Timeserver wird dadurch nicht korrigiert Fehler ist in der Regel gering, da typisch Verarbeitungsdauer << Übertragungsdauer ist Server T1 T = 2 0 TS T S T x t Fehler Client T 0 T T 1 T 1 T0 0 T 1 2 t d r T 1 T 0 2 d r d r d req T 1 T 0 d req d rep d rep C. Grimm 14. Juli 2004 Folie 26

27 Berkeley Algorithmus Eigenschaften Ablauf zentraler Algorithmus aktiver Server Server hat nicht notwendigerweise eine mit einem Zeitnormal abgeglichene Uhr Ziel ist lediglich die Synchronisation der Systemzeiten einer Gruppe von Rechnern bei Ausfall des Servers übernimmt einer der Clients dessen Funktion der Server ruft regelmäßig die aktuelle Systemzeit von allen Clients ab aus den Ergebnissen bildet der Server einen Mittelwert Ausreißer werden bei der Berechnung ignoriert individuelle Differenz zum Mittelwert (d. h. Offset) wird an jeden Client gemeldet Laufzeitschwankungen Clients stellen ihre Uhren nach dem übermittelten Offset Nachteil skaliert nur bedingt verschieden Gruppen haben unterschiedliche Zeiten C. Grimm 14. Juli 2004 Folie 27

28 Berkeley Algorithmus Beispiel Ablauf Server ruft von allen Clients deren lokale Uhrzeit ab Server sortiert Ausreißer aus hier Uhrzeit von Client C Server bildet aus verbleibenden Uhrzeiten Mittelwert Server 6:56-0:14 6 : : : 56 3 = 6 : 42 Server sendet allen Clients Offset zu deren lokaler Uhrzeit auch an Ausreißer 6:30 6:40 3:40 +0:12 +0:02 +3:02 Client A Client B Client C 6:30 6:40 3:40 C. Grimm 14. Juli 2004 Folie 28

29 Logische Zeit Vorüberlegung es ist unmöglich, physikalische Uhren absolut zu synchronisieren viele Prozesse benötigen aber Informationen über die Reihenfolge von Ereignissen viele Prozesse benötigen jedoch keinen Bezug zur realen Zeit Forderung die Reihenfolge von Ereignissen soll absolut angebbar sein Bezug zur realen Zeit ist nicht notwendig Definition einer logischen Zeit wenn zwei Ereignisse in einem Prozess stattfinden, dann entspricht die Reihenfolge ihrer Beobachtung ihrem Eintreten wird eine Nachricht von einem Prozess an einen anderen gesendet, dann tritt das Ereignis a Senden vor dem Ereignis b Empfang ein (Kausalität) Lamport führt die Relation passiert vor (happened before) ein Schreibweise: a b gelesen: a passiert vor b C. Grimm 14. Juli 2004 Folie 29

30 Logische Zeit die Relation Happened Before Kausalität wenn gilt a b und b c, dann folgt daraus auch a c Nebenläufigkeit von Ereignissen wenn die Ereignisse x und y in verschiedenen Prozessen auftreten, die keine (auch nicht mittelbar) Nachrichten austauschen, gilt weder x y noch y x diese Ereignisse werden nebenläufig genannt, d. h. es ist keine Aussage über ihre zeitliche Reihenfolge möglich. Definition einer logischen Uhr bei Eintreten des Ereignisses a liefert die logische Uhr einen Zeitwert C(a), der im gesamten System eindeutig ist. wenn innerhalb eines Prozesses die Ereignisse a und b auftreten und a b, dann gilt C(a) < C(b) wenn a das Senden einer Nachricht und b deren Empfang beschreibt, dann gilt C(a) < C(b) weiterhin muss C monoton vorwärts laufen C. Grimm 14. Juli 2004 Folie 30

31 Logische Zeit Lamport Algorithmus Annahme Uhrenfrequenzen sind gleich Uhr 1 Uhr 2 Uhr 3 Inkremente pro Interrupt sind jedoch unterschiedlich Uhr 0: Inkrement von 6 pro Interrupt Uhr 1: Inkrement von 8 pro Interrupt Uhr 2: Inkrement von 10 pro Interrupt A Problem Rechner 1 und 2 empfangen Nachrichten mit einem Timestamp größer als der lokalen Systemzeit bei Uhr auf Rechner 2 = 56 Bei Uhr auf Rechner 1 = B C Rechner 1 und 2 können Nachrichten nicht zeitlich korrekt einordnen Reihenfolge von Ereignissen entspricht nicht den Timestamps D C. Grimm 14. Juli 2004 Folie 31

32 Logische Zeit Lamport Algorithmus Lösung Einführung einer logischen Zeit Uhr 1 Uhr 2 Uhr 3 Ansatz jede Nachricht enthält im Header einen Timestamp mit der Zeit des Aussendens A jeder Rechnern prüft bei Eintreffen einer Nachricht diesen Timestamp B Fallunterscheidung ist der Timestamp kleiner als aktuelle Systemzeit? keine Aktion C ist der Timestamp größer als aktuelle Systemzeit? setze Systemzeit auf den Wert Timestamp D d. h. keine Verletzung der Monotonie C. Grimm 14. Juli 2004 Folie 32

33 Uhren-Synchronisierung im Internet Einführung einer einheitlichen Zeitrechnung zählen der Sekunden seit dem in 64-Bit-Zahl 32 Bit für Sekunden, 32 Bit für Bruchteile von Sekunden Zeitangabe gemäß UTC Überlauf alle 136 Jahre deshalb zusätzlich Zeitzählung in Epochen Beginn der nächsten Epoche 2036 Protokolle zur Zeitsynchronisierung J. Postel, K. Harrenstien. Time Protocol. IETF RFC 868, Mai 1983 (auch IETF STD 26) bekannte Implementierung als rdate timed lediglich Implementierung eines Daemon in BSD-Unix, kein als RFC spezifiziertes Protokoll D. L. Mills. Network Time Protocol (Version 3) Specification, Implementation and Analysis. IETF RFC 1305, März 1992 Version 4 von NTP ist seitdem in Entwicklung... D. L. Mills. Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. IETF RFC 2030, Oktober 1996 nicht verwechseln mit NTP Version 4! C. Grimm 14. Juli 2004 Folie 33

34 Synchronisation mit rdate Spezifikation J. Postel, K. Harrenstien. Time Protocol. IETF RFC 868, May 1983 Eigenschaften: einfaches Protokoll über TCP oder UDP Auflösung von 1 s keine Ermittlung der Übertragungszeit Fehler in lokaler Uhr (Drift) wird nicht kompensiert keine Authentisierung / Verschlüsselung der Zeit Ablauf Client: Connect an Port 37 bzw. Senden eines leeren UDP-Datagrams Server: Senden der Zeit als binärer 32-Bit Wert historisches Beispiel, in der Praxis nicht mehr relevant C. Grimm 14. Juli 2004 Folie 34

35 Synchronisation mit timed Entwickelt für BSD Unix 4.3 Protokoll Master-Slave-Beziehungen enthält Zeit- und Kontrollnachrichten synchronisiert Hosts in einem Netz bezüglich der Netz-Zeit, die als Mittelwert der Master-Zeiten gebildet wird ermöglicht hierarchisches Verteilen der Netz-Zeit auch über Subnetzgrenzen hinweg Übertragung der Zeit als 64-Bit-Wert (32 Bit Sekunden, 32 Bit Fraction) Eigenschaften Auflösung ~ s (0,2 ns) Anpassung der lokalen Uhr mittels adjtime () keine Ermittlung der Übertragungszeit keine Authentisierung / Verschlüsselung der Zeit historisches Beispiel, in der Praxis nicht mehr relevant C. Grimm 14. Juli 2004 Folie 35

36 Network Time Protocol NTP Spezifikation D. L. Mills. Network Time Protocol (Version 3) Specification, Implementation and Analysis. IETF RFC 1305, März 1992 aktuell ist bereits Version 4, noch nicht als Draft oder RFC standardisiert Ziele Synchronisation der Clients auf UTC Korrektur von Fehlern, die durch variable Verzögerung im Netzwerk verursacht wurde Ausfallsicherheit durch Synchronisierung mit mehreren Timeserver (Peers) gute Skalierbarkeit Eigenschaften Bildung einer Hierarchie von Servern mit abgestufter Genauigkeit Nutzung von UDP zur Übermittlung der Zeitinformationen Berücksichtigung der Übertragungszeit im Netz bei der Korrektur der Systemzeit beinhaltet Authentifizierung und verschlüsselte Zeitmarken Auflösung ~ s (0,2 ns) überträgt die Zeit als 64-Bit Wert (32-Bit Sekunden, 32-Bit Fraction) C. Grimm 14. Juli 2004 Folie 36

37 Simple Network Time Protocol SNTP Spezifikation D. L. Mills. Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. IETF RFC 2030, Oktober 1996 Protokoll interoperabel mit NTP Synchronisierung auch über IP Broadcast, Multicast, Anycast möglich, hierbei sind Authentifizierungsverfahren nötig Eigenschaften ein Client verwendet i.d.r. nur einen Server als Quelle stark vereinfachte Architektur (kein Filter/Intersection-Algorithmus) ggf. Vernachlässigung der Übertragungszeit daher Einsatz nur am Netzrand bei Clients, die keine weiteren Rechner synchronisieren C. Grimm 14. Juli 2004 Folie 37

38 Implementierung von NTP-Servern NTP-Server werden hierarchisch angeordnet Ebenen in der NTP-hierarchie werden als Stratum bezeichnet Stratum 1: Server mit primärer Zeitquelle wie Atomuhr, Funkuhr etc. Stratum 2: Verteilungsebene z. B. in Weitverkehrsnetzen Stratum 3: Verteilungsebene z. B. in lokalen Netzen Stratum 4: Clients: Arbeitsplatzrechner, Workstations über installierte NTP-Server weltweit verfügbar Internet primary servers (stratum 1) campus secondary servers (stratum 2) department servers (stratum 3) workstations (stratum 4) Implementierung der Daemon-Prozesse typisch unter UNIX mit xntp (ebenfalls von D. L. Mills) durch aufwändige Implementierung zusätzliche Features und hohe Qualität der Uhr NTP erreicht eine Genauigkeit von < 1 ms in LAN, von einigen 10 ms im Internet C. Grimm 14. Juli 2004 Folie 38

39 Betriebsmodi von NTP Multicast Time-Server versendet periodisch Nachrichten an die Clients per Multicast für Netzwerke mit geringer Latenz nur geringe Genauigkeit erzielbar keine Rückmeldung von den Clients Procedure-Call gegenüber dem Multicast Modus erhöhte Genauigkeit nutzt Cristians Algorithmus symmetrischer Modus höchste erzielbare Genauigkeit paarweiser Nachrichtenaustausch jede Nachricht enthält drei Timestamps den Sende- und Empfangszeiten der vorherigen Nachricht und der Sendezeit der aktuellen Nachricht C. Grimm 14. Juli 2004 Folie 39

40 Header in NTP Aufbau LI leap warning indicator VN version number (4) Strat stratum (0 15) Poll poll interval (log 2 ) Prec precision (log 2 ) LI VN 32 Bit Mode Strat Poll Root Delay Root Dispersion Reference Identifier Reference Timestamp (T 0 ) Originate Timestamp (T 1 ) Prec NTP v3 and v4 NTP Timestamp Format (64 bit) Cryptosum Receive Timestamp (T 2 ) Seconds (32) Fraction (32) Value is in seconds and fraction since 00:00:00 on 1 January 1900 NTPv4 Extension Field Field Length Field Type Extension Field (padded to 32-bit boundary) Last field padded to 64-bit boundary Authenticator (Optional) Transmit Timestamp (T 3 ) Extension Field 1 (optional) Extension Field 2 (optional) Key/Algorithm Identifier Message Hash (64 or 128) NTP v4 only Authenticator uses DES-CBC or MD5 cryptosum of NTP header plus extension fields (NTPv4) C. Grimm 14. Juli 2004 Folie 40

41 Architektur eines NTP-Servers Aufbau Server 1 Clock Filter 1 Server 2 Server 3 Clock Filter 2 Clock Filter 3 Intersection and Clustering Algorithms Combining Algorithm NTP Algorithms Loop Filter P/F-Lock Loop NTP Associations LCO Test durch mehrere Zeitquellen wird Redundanz und Vielfalt erreicht Clock filters selektieren das beste Fenster aus 8 Zeitproben Intersection and Clustering Algorithmen ermitteln die beste Teilmenge an Servern und verwerfen Ausreißer Combining Algorithmen gewichten Resultate Loop Filter und Local Clock Oszillator implementieren eine hybride Phasen/Frequenzregelschleife um Jitter und Drift zu minimieren C. Grimm 14. Juli 2004 Folie 41

42 Filter-Algorithmus in NTP Schätzung der Differenz Zeitdiagramm von Request und Reply Server T 2 θ S T 3 t δ 1 = T 2 T 1 δ 2 = T 4 T 3 θ Client letztes Stellen der Uhr t T 0 T 1 θ C T 4 zunächst Berechnung der Laufzeit (Delay) δ = δ 2 + δ 1 = (T 4 T 3 ) + (T 2 T 1 ) = (T 4 T 1 ) (T 3 T 2 ) Schätzung der Differenz beider Uhren (Offset) θ = θ S θ C ~ (T 3 T 2 )/2 (T 4 T 1 )/2 = (δ 1 δ 2 )/2 tatsächliche Differenz (Offset) θ δ/2 θ 0 θ+ δ/2 Folgerung: Der genaueste Offset θ wird bei der geringsten Verzögerung δ gemessen C. Grimm 14. Juli 2004 Folie 42

43 Literatur und weitere Informationen zu NTP A. Tanenbaum, M. v. Steen. Distributed Systems: Principles and Paradigms. Prentice Hall, 2002 G. Colouris, J. Dollimpore, T. Kindberg. Distributed Systems: Concepts and Design. 3rd Ed. 2001, Pearson Education Ltd. Network Time Protocol (NTP) Current NTP Version 3 and 4 software and documentation FAQ and links to other sources and interesting places Homepage David L. Mills Sources xntp ftp://ftp.udel.edu/pub/ntp Current NTP Version 3 and 4 software and documentation repository Collaboration resources repository Blueprints von Sun Microsystems Using NTP to Control and Synchronize System Clocks Part I: Introduction to NTP Using NTP to Control and Synchronize System Clocks Part III: NTP Monitoring and Troubleshooting C. Grimm 14. Juli 2004 Folie 43

44 Übersicht Motivation und Beispiele Zeiteinheit und Zeitsysteme Grundbegriffe der Zeitmessung Genauigkeit einer Uhr Offset zwischen zwei Uhren Uhren in Rechnern Kompensieren von driftenden Uhren Disziplinierung einer lokalen Systemuhr Synchronisation von Uhren in verteilten Systemen Algorithmus von Cristian Berkeley Algorithmus Lamport Algorithmus logische Zeit Network Time Protocol C. Grimm 14. Juli 2004 Folie 44