Die aktuelle Zeit soll von einem ntp-Server abgerufen werden (über ein
GPRS-Moduzl, angesteuert von einem MC).
Das klappt auch grundsätzlich, aber der ntp-Server (ptbtime1.ptb.de)
antwortet in ca. der Hälfte der Fälle nicht innerhalb von 3 Sekunden auf
die Anfrage (länger warte ich nicht).
Was habt ihr für Erfahrungen gemacht ?
- Ist es normal, dass nicht immer eine Antwort kommt ?
- Was macht ihr bei fehlender Antwort ? (länger warten, ggf. wie lange
?, nochmal beim gleichen Server probieren, bei einem anderen Server
anfragen, Kombilösung ?)
- welche ntp-Server antworten nach Eurer Erfahrung am schnellsten ?
Da das ganze über UDP läuft, ist es völlig normal, dass mal keine
Antwort kommt, weil ein Paket verloren geht. Zumal du GPRS nutzt, gilt
das umso mehr.
Allerdings sind 50% Paketverlust viel zu viel und liegen nicht an
ptbtime1.ptb.de: Im Test habe ich 70 ms Latenz und keinen Paketverlust.
Daher: Auf jeden Fall mehrmals probieren.
Probiere mal, was oszi40 meint. Wenn andere NTP-Server genauso schlecht
antworten, ist deine Netzwerkverbindung schuld. Ist's etwa das
berüchtigte E-Plus-Netz? ;-) Oder vielleicht deine Anbindung an das
GPRS-Modul…
Guck dir mal die RTT zu deinen NTP-Servern an. GPRS habe ich so mit 1-2
Sekunden Latenz in Erinnerung, dann wären deine 3 Sekunden ausreichend,
da die NTP-Server sofort oder gar nicht antworten.
Wenn der Server einmal nicht antwortet, mehrmals probieren, mit ein
wenig Verzögerung.
Ein „großer“ NTP-Client auf einem Rechner spricht mit mehreren Servern
parallel, aber das ist auf einem µC mehr Aufwand als nötig. Dort lohnt
es nur, falls du die aktuelle Zeit schon ganz schnell nach dem Start des
Systems wissen musst und deine Server unzuverlässig sind
(unwahrscheinlich).
Also: Server nacheinander probieren, falls einer gar nicht antwortet.
Mal so aus Interesse: Wie groß ist eigentlich die Varianz bei den
Antwortzeiten?
@Dennis : Danke für die Hinweise.
Ja, ich nutze das eplus-Netz. Aber ob es daran liegt, kann ich (noch)
nicht definitiv sagen.
Bzgl. Deiner Frage zur Varianz bei den Antwortzeiten :
Weiss ich noch nicht, denn ich muss die Auswertung der 48 Bit langen
Antwort noch implementieren und suche dazu auch noch eine übersichtliche
Beschreibung des Formates.
Die ntp-Dokus, die ich bisher im Netz gefunden habe, sind extrem
unübersichtlich und lang.
Die reine Beschreibung des Datenformates der 48 Byte kann doch nicht so
kompliziert sein ?
Du kannst z.B. in den Ethersex-Code gucken, die haben einen NTP-Client
implementiert (services/ntp/ntp.?), falls du dir nicht RFC 4330
durchlesen möchtest.
Im Paket ist ein Unix-Zeitstempel enthalten. Diese Zahl in ein
menschenlesbares Datenformat umzuwandeln, ist eine andere Aufgabe. Dazu
findest du aber auch genug Code (Ethersex: clock_localtime, wo wir
gerade dabei sind).
Dennis S. schrieb:> Im Paket ist ein Unix-Zeitstempel enthalten.
Welche Bytes das genau sind, kannst Du nicht ev. aus dem Stegreif sagen
?
Damit wäre für mich der Fall gelöst, weil mir eine Genauigkeit von einer
Sekunde für die Systemzeit ohne weiteres ausreicht.
Aus ntp_fp.h, was mit FreeBSD mitgeliefert wird, vereinfacht:
1
structntp_pkt{
2
uint8_tli_vn_mode;/* leap indicator, version and mode */
3
uint8_tstratum;/* peer stratum */
4
uint8_tppoll;/* peer poll interval */
5
signedcharprecision;/* peer clock precision */
6
uint32_trootdelay;/* distance to primary clock */
7
uint32_trootdispersion;/* clock dispersion */
8
uint32_trefid;/* reference clock ID */
9
l_fpreftime;/* time peer clock was last updated */
10
l_fporg;/* originate time stamp */
11
l_fprec;/* receive time stamp */
12
l_fpxmt;/* transmit time stamp */
13
/* No extension included here */
14
};
15
typedefstruct{
16
uint32_ttimestamp;
17
uint32_tfraction;
18
}l_fp;
"timestamp" bezieht sich allerdings auf das Jahr 1900 statt wie bei Unix
üblich 1970 (also +2208988800 Sekunden, falls du den Unix-Zeitstempel
willst). Die Zeit vom Server steht in "rec" drin.
Sollten also die Bytes 32 bis 36 sein.
Ok, die Bytes 32 bis 35 des Blocks (bzw. im gesamten Antwortstring des
ntp-Servers die Bytes 113 - 116) enthalten die vier Bytes der Sekunden
seit dem 1.1.1900
Wiess ev. noch jemand spontan, ob und ggf. wo (in welchen Bytes) in dem
Anwortstring Angaben zur Zeitzone enthalten sind ?
Beim letzten Test wurde die Zeit von ptbtime1.ptb.de in MEZ und nicht
UTC (bzw. GMT) zurückgegeben.
Johannes G. schrieb:> Ich dachte es wird immer UTC übertragen. Die Interpretation (sezten der> richtigen Zeitzone) ist Aufgabe von deinem lokalen System.
Das dachte ich auch. Der ntp-Server schickt die Zeit aber eindeutig mit
der MEZ-Zeitzone (habe das gerade nochmal überprüft).
Liegt es ev. an der Anforderung oder gibt es in der Antwort eine
Sequenz, in der die Zeitzone angegeben ist. Im Anhang poste ich mal die
Anfrage, die Antwort des ntp-Servers und die Umrechung in die Unix-Zeit.
Vielleicht hat ja jemand noch eine Idee, bevor ich die Spezifikationen
wälzen muss.
Der vom ntp-Server (ptbtime1.ptb.de) zurückgelieferte Zeitwert gibt mir
immer noch Rätsel auf :
Auf meine Anforderung am 09.05.2012 um 10:06:17 (MESZ) bekomme ich in
der Antwort (Byte[absolut/Antwortanteil relativ]) :
Byte[113/32]=211 Byte[114/33]=84 Byte[115/34]=163 Byte[116/35]=249
das ergibt eine ntp-Zeit von 3545539577
Die Korrektur (1.1.1900 - 1.1.1970) -2208988800 ergibt eine ntp_unixzeit
von 1336550777
Laut http://www.aritso.net/aritso-tools/timestampconverter/ entspricht
die Unixzeit 133655077 für UTC0 der Zeit 09.05.2012 um 09:06:17 Uhr.
Aber tatsächlich ist UTC=(MESZ-2), es müsste also 08:06:17 Uhr
zurückgeliefert werden, wenn der ntp-Server die UTC-Zeit überträgt ?
Danke für den Check, was für einen Server hast Du verwendet ?
Ich baue die Verbindung übver GPRS und eplus auf, das dauert manchmal
auch etwas länger :-)
anfaenger schrieb:> Danke für den Check, was für einen Server hast Du verwendet ?
Einen netzinternen. Der eigentlich Punkt ist aber ein anderer: Im NTP
existiert wie erkennbar kein Feld, welches eine Zeitzone des Servers
oder eine Differenz zu UTC definiert. Da der Client also nicht wissen
kann, in welcher Zeitzone der Server sitzt, kann NTP über
Zeitzonengrenzen hinweg nur funktionieren, wenn alle angegebenen Zeiten
UTC sind.
Der Anfragestring ist ja 48 Zeichen lang. Da ich nicht die Bedeutung
aller Bytes kenne, bin ich mir auch nicht sicher, ob da irgendwo Platz
für Angaben zur gewünschten Zeitzone ist.
Ich verwende wohl den Basis-Anfragestring, der wird aber offensichtlich
akzeptiert.
anfaenger schrieb:> Der Anfragestring ist ja 48 Zeichen lang. Da ich nicht die Bedeutung> aller Bytes kenne, bin ich mir auch nicht sicher, ob da irgendwo Platz> für Angaben zur gewünschten Zeitzone ist.
Die Formate von Request- und Reply-Paket sind gleich. Der einzige
Unterschied liegt im Inhalt der Flags Bitmap.
NTP funktioniert innerhalb eines LANs auch per Broadcast. Eine Station
kann dann die Uhrzeit einfach vom Netz fischen ohne explizit anzufragen.
Zur Info (aus diesem Thread :
Beitrag "Zeit und Datum aus Unix-Zeit, schlanker Code gesucht;")
Echt klasse !
Damit hat sich auch das NTP-Problem aus diesem Thread erledigt :
Beitrag "Zeit von ntp-Server abrufen;"
Für die Unix-Zeit 1336550777 liefert der Code von Bernhard den korrekten
UTC Datum/Zeit-Wert 20120509 08:06:17 (JJJJMMTT HH:MM:SS)
Ich war schon ziemlich genervt, weil die Zeiten eines ntp-Servers ja
prinzipiell im UTC-Format übermittelt werden sollten, mir dieser Link
http://www.aritso.net/aritso-tools/timestampconverter/ aus dem
Unix-Zeitwert aber immer UTC+1 (=MEZ) berechnet hat (auch wenn UTC
vorgegeben war)
Das Ergebnis lautet z.B. für die oben verwendete Unix-Zeit
"Der Timestamp 1336550777 entspricht dem 09.05.2012 um 09:06:17 Uhr.
(gilt für UTC 0)"
THX !
