Archiv verlassen und diese Seite im Standarddesign anzeigen : HS: Fehlermeldungen..
Meudenbach
30.04.07, 08:29
Kann mir jemand sagen, was diese Meldung bedeutet:
Steht in der Debug Liste unter [Exceptions]
29.04.2007 22:00:17 (6)
File "/hs/compile/hs_comm.py", line 2257, in checkTimeServer
error: (111, 'Connection refused')
... ich vermute einen fehlerhaften NTP Eintrag :o.
LG
File "/hs/compile/hs_comm.py", line 2257, in checkTimeServer
error: (111, 'Connection refused')
... ich vermute einen fehlerhaften NTP Eintrag :o.Würde ich genauso sehen. Oder halt evtl. ein Paketfilter auf dem Weg zum NTP Server.
Matthias Schmidt
30.04.07, 10:33
Oder zuviele Connections.
Oder zuviele Connections.NTP benutzt UDP, da gibt es so etwas wie "zuviele Connections" nicht. Entweder es klappt oder halt nicht, es ist halt verbindungslos.
NTP benutzt UDP, da gibt es so etwas wie "zuviele Connections" nicht. Entweder es klappt oder halt nicht, es ist halt verbindungslos.
Tja, nicht überall wo NTP druff steht, is auch NTP drin :p
Der Homeserver verwendet kein NTP zur Zeitsynchronisation. Der Grund hierfür liegt wohl daran dass NTP im Prinzip eine permanente Internetverbindung benötigt.
Der Homeserver verwendet das Time protokol das UDP oder TCP verwendet.
Nun zur eigentlichen Fehlermeldung: "Connection refused" ist eine typische TCP Fehlermeldung die zum einen bedeutet dass die angesprochene IP adresse tatsächlich vorhanden ist (i.e. geantwortet hat), zum anderen aber kein server am angesprochenen Port lauscht. Sprich: Entweder ist die IP adresse falsch, oder der Zeitserver nicht gestartet. Läuft auf dem Server jedoch nur NTP, wirds nicht klappen :shithappe
Gruss,
Gaston
Tja, nicht überall wo NTP druff steht, is auch NTP drin :p
Der Homeserver verwendet kein NTP zur Zeitsynchronisation. Der Grund hierfür liegt wohl daran dass NTP im Prinzip eine permanente Internetverbindung benötigt.
Der Homeserver verwendet das Time protokol das UDP oder TCP verwendet.
ich würd mir wünschen , dass Gira/Dacom dies mal in der Hilfe korrigiert . Das hat schon zu erheblichem Aufwand geführt bei einer Zeitabfrage auf einem Zeitserver im Netz und der Schaden blieb bei uns hängen ...
ich würd mir wünschen , dass Gira/Dacom dies mal in der Hilfe korrigiert . Das hat schon zu erheblichem Aufwand geführt bei einer Zeitabfrage auf einem Zeitserver im Netz und der Schaden blieb bei uns hängen ...
Hallo Norbe,
habe deine Anregung direkt weitergeleitet. Die Hilfe wird um diese Information erweitert und steht ab der neuen Experten Version 2.2 demnächst zur Verfügung.
Vorab zur Info, es handelt sich bei dem verwendeten Zeitprotokoll um das RFC-868 welches über den Port 37 arbeitet. Der Port wird über die RFC vorgegeben.
Wir empfehlen ebenfalls die in der Online Hilfe angegebenen Zeitserver einzusetzen da diese getestet wurden und funktionieren.
Ach nee, was soll das denn?
Anstatt die Hilfe zu korrigieren solltet Ihr das einbauen was sich in den letzten ca. 10 Jahren zum De Facto-Standard Entwickelt hat.
TIME hat mittlerweile fast nur noch folkloristische Bedeutung.
Die Zahl der brauchbaren TIME-Server kann man mittlerweile an seinen zehn Fingern abzählen.
In den letzten zehn Jahren hat die ganze Welt (vielleicht bis auf ein kleines gallisches Dorf) seine Systeme auf NTP nach RCF 1305 umgestellt, jeder bessere Router kann RCF und es gibt im grossen weiten Internet Server die öffentlich Zeitsynchronisation via NTP anbieten, da könnte der HS mal nachziehen und NTP implementieren - so gross kann der Aufwand dafür nicht sein.
TIME hat keinerlei Mechanismen um mit Latenzen oder Jitter umzugehen, man hat keine Prüfsummen oder sonst welche Sicherheitsmechanismen um kaputte Zeiten zu erkennen - mit etwas Glück läuft TIME im Sekundenbereich "präzise", das könntet Ihr echt mal abtreiben.
Gruss
Markus
TIME hat keinerlei Mechanismen um mit Latenzen oder Jitter umzugehen, man hat keine Prüfsummen oder sonst welche Sicherheitsmechanismen um kaputte Zeiten zu erkennen - mit etwas Glück läuft TIME im Sekundenbereich "präzise", das könntet Ihr echt mal abtreiben.
Gruss
Markus
Das Argument der schwindenden Timeserver ist nicht von der Hand zu weisen. Ich für meinen Teil wünsche mir ja uahc NTP für den HS, allerdings braucht NTP, soweit man die angesprochene Genauigkeit will, eine immer offene Internet Verbindung, was für den HS Einsatzt u.U. Problematisch sein kann.
Auf der anderen Seite warne ich vor solchen Pauschalaussagen was NTP betrifft. Es stimmt schon dass NTP im Prinzip sehr genau sein kann, jedoch muss man wissen dass nicht jede Implementation das volle NTP unterstützt. Windows z.B. synchronsiert sich auch per NTP, und dennoch ist die synchronisation nicht genauer als ein Time-Protocol synchronisation !
Dazu eine kleine OT Warnung: man sollte keinen Windows rechner mit standard NTP server als internen NTP server einsetzen ! (Es sei denn es synchronisieren sich nur Windows Rechner darauf ;) )
Gruss,
Gaston
Windows bis 2000 verwendet von Haus aus SNTP nach RFC 2030 (zwischenzeitlich ersetzt durch RFC 4330), erst mit XP bzw. 2003 ff. hat MS auf NTP umgestellt - wobei die immer noch SNTP können. Im Prinzip ist SNTP ein Subset von NTP, das eigentliche Protokoll ist identisch.
Ich stimme zu dass ein "echter", weitestgehend Feature-kompletter NTP im HS wünschenswert ist - wobei jede denkbare NTP/SNTP-Implementierung im HS wahrscheinlich besser wäre als der antiquierte TIME. Ich habe schon öfters TIME-"synchronisierte" Systeme gesehen die im "Normalbetrieb" mehrere Minuten daneben getickt sind - und wir hatten auch mal einen OpenVMS-Hobel den es via TIME nach von 1999 nach 1950 gebeamt hat weil irgendwo im TIME-Paket ein Bit gekippt ist - peinlich wenn an der Maschine die Synchronisation für ein etwas grösseres Netz - oder die GLT - hängt und etliche Crons (oder Zeitschaltuhren) plötzlich anfangen Amok zu laufen. NTP hat Mechanismen um solche Zeitreisen zu unterbinden - und der HS als linuxbasierende Appliance sollte eigentlich von Haus aus alles für eine saubere NTP-Implementierung mitbringen. Die Hardware-Clock im HS müsste eigentlich so präzise sein dass sie den HS über mehrere Stunden annähernd sekundengenau im Takt hält ohne dass eine Zeitsynchronisation statffindet - und der Clock dürfte es herzlich egal sein ob sie über TIME oder über (S)NTP nicht synchronisiert wird - und ob über 37/UDP oder über 123/UDP gesynct wird dürfte der Firewall auch egal sein - abgesehen davon dass 123/UDP eh meistens offen ist weil nicht nur der HS ans NTP will.
Gruss
Markus
Windows bis 2000 verwendet von Haus aus SNTP nach RFC 2030 (zwischenzeitlich ersetzt durch RFC 4330), erst mit XP bzw. 2003 ff. hat MS auf NTP umgestellt - wobei die immer noch SNTP können. Im Prinzip ist SNTP ein Subset von NTP, das eigentliche Protokoll ist identisch.[/quota]
Naja, wollte mir die Details sparen, aber das ist nicht ganz richtig, sowohl Windows XP wie auch 2003 benützen ursprünglich SNTP (und dies auch noch nicht RFC konform). Erst im SP1 für Windows 2003 ist ein NTPv3 server enthalten. Ich hatte leider noch keine Gelegenheit mir dessen Pakete anzusehen.
SNTP ist nicht genauer wie Time. Das Protokol ist in soweit gleich mit NTP als dass die Pakete das gleiche Format haben, jedoch die Felder die für die Zeitkorrektur verantwortlich sind (z.B. Paket Laufzeit) werden mit default werten so bestückt als wären keine Laufzeiten und andere Fehler vorhanden.
[QUOTE]
Ich habe schon öfters TIME-"synchronisierte" Systeme gesehen die im "Normalbetrieb" mehrere Minuten daneben getickt sind
Daran konnte das Protokol dann aber nichts. Anders gesagt: Ich habe schon öfters Autos gesehen die schneller als erlsaubt gefahren sind. War daran das Autio schuld ? Natürlich nicht.
Der Offset des time clients zum server ist so gross wie die Summe der Bearbeitungszeiten der Pakete auf beiden seiten sowie die Laufzeit dazwischen. Und das dürfte niemals ein Minutenwert sein. Sogar wenn dies der Fall wäre, dann ginge es NTP nicht viel besser da die prozentual zu erwartenden fluktuationen der Zeit zu gross wären um korrigiert zu werden.
- und wir hatten auch mal einen OpenVMS-Hobel den es via TIME nach von 1999 nach 1950 gebeamt hat weil irgendwo im TIME-Paket ein Bit gekippt ist
Hmm, wer 1999 OpenVMS mit einem Time server synchronisiert (freeware oder thirdparty) ist eigentlich selber schuld. 1999 kann OpenVMS schon lange NTP :p
Ausserdem die Berichte über solche Bitkipp Phenomene finde ich immer wieder interessant. Zum einen, ist das Bit im Netzwerk gekippt wäre das Paket niemals beim Time client angekommen denn es wäre auf derTCP/UDP Schicht wegen Checksummen Fehler abgewiesen worden. Zum anderen, ist das Bit intern in der Maschine gekippt so kann das bei jedem protokol zu einem Zeitpunkt passieren zu dem es zu Fehlinterpretationen führt.
Meistens sind solche Geschichten einfach die Frucht des gescheiterten Versuch einer Erklärung des Problems.
- peinlich wenn an der Maschine die Synchronisation für ein etwas grösseres Netz - oder die GLT - hängt und etliche Crons (oder Zeitschaltuhren) plötzlich anfangen Amok zu laufen.
Peinlich wenn man in dem Fall nicht NTP verwendet :D
NTP hat Mechanismen um solche Zeitreisen zu unterbinden
NTP wird zwar keine so grossen Sprünge machen, aber generell hat NTP, als Protokol, nichts in seinem Protokol was Zeitreisen verhindert. Das einzige was Das verhinder ist i.d.R eine Zeitoffsetbegrenzung die jedoch nicht mit dem Protokol zu tun hat. Durch diese Begrenzung schaltet NTP sich ab wenn die lokale Uhr z.B. mehr als 15 Minuten aus dem Ruder gegenüber dem Server läuft.
Die Hardware-Clock im HS müsste eigentlich so präzise sein dass sie den HS über mehrere Stunden annähernd sekundengenau im Takt hält ohne dass eine Zeitsynchronisation statffindet -
Die Hardware clock wird bei Computern in aller Regel nicht während des Betriebs genutzt da das auslesen viel zu langsam ist. Deshalb wird eine interrupt gesteuerte Software Uhr verwendet die ungenau ist da die Timerinterrupts nicht immer sofort ausgeführt werden können.
und der Clock dürfte es herzlich egal sein ob sie über TIME oder über (S)NTP nicht synchronisiert wird
Die synchronisation per Time/SNTP im Kernel ist grundverschieden. In der regelr wird bei Time NTP nur einmal am Tag synchronsisiert und die Zeit einfach gesetzt. Dabei wird auch die HW Clock gestzt. Bei NTP wird per adjtime() jedoch die Zeit gedriftet. der grosse Vorteil ist dass die Uhr niemals Rückwärts läuft (Winterzeitumschaltung mal ausgenommen). Dies wäre beim HS wegen den Archiven wünschenwert. Allerdings gehen in den meisten Fällen die Computeruhren eher nach als vor. Bei Hardware Problemen kann eine Uhr aber auch schon mal sehr schnell vor gehen :D
Gruss,
Gaston
Ohne auf die technischen Aspekte einzugehen, hier mal der Auszug aus der Debugseite meines HS:
Abweichung 3.68 2.68 3.51 3.76 3.55
Diese Abweichungen sind IMHO eindeutig im grünen Bereich.
Die Abweichung meines relativ stark beanspruchten Beta-Test HS liegen im ähnlichen Bereich.:)
Vorab zur Info, es handelt sich bei dem verwendeten Zeitprotokoll um das RFC-868 welches über den Port 37 arbeitet. Der Port wird über die RFC vorgegeben.Wie ja einige schon gesagt haben ist das TIME Protocol nicht mehr der Stand der Dinge. Allerdings sehe ich genau wie viele andere das Problem das man nicht davon ausgehen kann, dass der HS immer online ist. Beim fli4l setzen wir deshalb chrony (http://chrony.sunsite.dk/) ein, das ist für den on-/offline Betrieb "optimiert". Zur Not könnte man damit sogar per ISDN die Zeit einmal am Tag holen, sicherlich immer noch günstiger als eine DCF77 Funkuhr mit EIB Anbindung.
Ohne auf die technischen Aspekte einzugehen, hier mal der Auszug aus der Debugseite meines HS:
Diese Abweichungen sind IMHO eindeutig im grünen Bereich.
Ich hab mal bei meinem nachgesehen und erstaunliches festgestellt:
Abweichung: 36.00 36.00 36.00 36.00 36.00
Die Synchronisation erfolg bei mir per EIB, und zwar Stündlich ! Die letzte Abweichung wird durch die Zeit des letzen Telegrams bestätigt: 04.05.2007 09:59:24
Gruss,
Gaston
Abweichung50.00 49.00 50.00 51.00 49.00 Letztes Update04.05.2007 09:59:11
Naja.
Gruss
Markus
Beim fli4l setzen wir deshalb chrony (http://chrony.sunsite.dk/) ein, das ist für den on-/offline Betrieb "optimiert". Zur Not könnte man damit sogar per ISDN die Zeit einmal am Tag holen, sicherlich immer noch günstiger als eine DCF77 Funkuhr mit EIB Anbindung.
Ja, ganz interessant, als xntp alternative. Das einzige was mir nicht so gefällt ist dass er mit Fliesskommazahlen arbeitet, aber im offline Betrieb ist das sowieso nebensächlich.
Etwas anderes worauf der Autor nicht hinweist (soweit ich es nicht übersehen habe9 ist dass es im offline Modus zu Problemen kommen kann wenn chrony als Server zum synchronisieren anderer NTP clients verwendet wird. Genau das ist auch eins der Probleme bei Windows, da es sich nur einmal täglich (o.ä.) synchronsiert (Bei Windows2003 SP1 bin ich mir da nicht sicher, wie oben beschrieben).
Aber für den HS wäre das Teil bestimmt ein guter Tip :)
Gruss,
Gaston
Abweichung: 36.00 36.00 36.00 36.00 36.00
Abweichung50.00 49.00 50.00 51.00 49.00 Letztes Update04.05.2007 09:59:11
Das sind Werte, die mich zu der Frage verleiten, welche Karenzzeit für den Zeitabgleich parametriert habt.
Darüberhinaus macht mich bei euren Zeiten
die immer gleiche Abweichung bei Gaston, und
die immer gleiche xx.00 bei Markus etwas stutzighttp://www.eib.agrodur.com/gtchat95/images/26.gif (http://javascript<b></b>:void(0))
Hallo Markus,
Ich denke bei Dir ist es wie bei mir, die Karenzzeit steht auf 60 Sekunden. Dachte eigentlich ich hätte das geändert :o
Man darf diese Zahlenreihe nicht falsch interpretieren. Sie gibt nicht direkt an wie genau die interne Uhr läuft. Innerhalb der Karenz Zeit wird die Uhr nicht verstellt, was bedeutet in meinem Beispiel läuft die Uhr innerhalb einer Stunde perfekt ! Bei Markus, davon ausgehend dass die karenzzeit auch bei 60 Sekunden steht, wäre es eine Abwichung von einer Sekunde. Da die Sprünge vor und zurück sind kann man daraus jedoch nicht Schlussfolgern dass die Tagesabwichung 24 Sekunden sei. Es dürfte sich dabei um einen "Rundungsfehler" handeln und somit liegt der Tagesfeheler innerhalb 1 bis 2 Sekunden.
Die Abweichung von Michel kann man so nicht interpretieren, ausser dass er das Timprotokol verwendet (bei EIB, immer 0 hinter dem Komma). Ist die Karenzzeit bei Ihm z.B. 5 Sekunden (>3 sek) dann beträgt der Zeitfehler +/-1Sekunde pro Tag, ist die Karenzzeit jedoch 1 Sekunde (odeder 2) dann entspricht der Zeitfehler der in der Liste stehenden Werten. (Nich dass das problematisch wäre, nur zur Verdeutlichung)
Problematisch finde ich es hingegen wenn eine negative Abweichung vorhanden ist, da diese unter Umständen einige Aktionen doppelt auslösen könnt.
Dies ist der Hauptgrund um NTP zu bevorzugen, und der Grund wieso NTP das Time-Protokol (und andere) abgelöst hat.
Gruss,
Gaston
Das sind Werte, die mich zu der Frage verleiten, welche Karenzzeit für den Zeitabgleich parametriert habt.
Du warst zu schnell :D Jup, dachte eigentlich ich hätte die auf eine Sekunde geändert, stand aber noch auf 60. Habs leider erst nach dem Post geprüft. :o
die immer gleiche Abweichung bei Gaston, und
Bedeutet nur dass meine Uhr innerhalb einer Stunde ganz genau geht ;)
die immer gleiche xx.00 bei Markus etwas stutzig
Dies kommt daher dass die EIB Synchronisation nur Sekunden genau ist.
Gruss,
Gaston
Mein HS synct täglich um 10:00 von ntp-2.uni-marburg.de
bzw. aixfile1.urz.uni-heidelberg.de. Meine Karenzzeit für "NTP" steht auf 60.
Im Prinzip ist mir die Differenz 88 da ich als Zeitreferenz für den EIB meine Elsner-Wetterstation mit eingebautem DCF77-Empfänger benutze.
Wenn ich das richtig sehe hat Gaston auch immer 00 hinter dem Komma. Dass der bei Gaston und mir "sekundengenaue" Abweichungen hat erstaunt mich nicht, ein Blick ins einschlägige RFC 868 führt zu der Erkenntnis dass TIME einfach die Anzahl der Sekunden seit 01.01.1900 00:00 Uhr liefert - vielmehr wüsste ich gerne die Antwort auf die Frage warum Dein HS die Abweichung auf 1/100 Sekunden genau angeben kann wenn das zugrunde liegende Protokoll für die Zeitsynchronisation per Definition nur sekundengenau arbeitet.
Gruss
Markus
@Michel:
time.nist.gov für TIME würde ich nicht verwenden. TIME hat keine Mechanismen um die Paketlaufzeiten zu berechnen und bei der Synchronisation zu berücksichtigen. Je "weiter" (Hops) der Zeitserver weg ist desto ungenauer wird die Zeit bei TIME - das ist systemimmanent. NTP hat Mechanismen um die Paketlaufzeiten zwischen Zeitserver und Client zu ermitteln und bei der Synchronisation zu berücksichtigen - da dürfte ein TIME-Server in DE fast immer die bessere (i.S.v. genauere) Wahl sein.
Gruss
Markus
time.nist.gov für TIME würde ich nicht verwenden. ... da dürfte ein TIME-Server in DE fast immer die bessere (i.S.v. genauere) Wahl sein.ACK! Der HS synchronisiert auch nur über ptbtime1.ptb.de . Muss bei Gelegenheit trotzdem mal die Einstellung ändern :o .
Gaston, Du schrubst weiter oben dass Du die HS-Zeit stündlich per EIB synchronisierst, d.h. Du hast auf dem EIB einen vom HS unabhängigen Zeitgeber und Dein HS synct zusätzlich 1x täglich via TIME?
Gruss
Markus
Matthias Schmidt
04.05.07, 12:22
Nr. 1
Abweichung-7.16 -0.08 -2.83 -6.51 -0.03 Letztes Update04.05.2007 04:29:59
Nr .2
Abweichung2.21 4.96 7.93 Letztes Update04.05.2007 04:30:13
Nr. 3
Abweichung-0.30 0.12 -0.45 -0.06 0.39
Die x.00 sind schon sehr merkwürdig.
Wenn ich das richtig sehe hat Gaston auch immer 00 hinter dem Komma. Dass der bei Gaston und mir "sekundengenaue" Abweichungen hat erstaunt mich nicht, ein Blick ins einschlägige RFC 868 führt zu der Erkenntnis dass TIME einfach die Anzahl der Sekunden seit 01.01.1900 00:00 Uhr liefert - vielmehr wüsste ich gerne die Antwort auf die Frage warum Dein HS die Abweichung auf 1/100 Sekunden genau angeben kann wenn das zugrunde liegende Protokoll für die Zeitsynchronisation per Definition nur sekundengenau arbeitet.
Gruss
Markus
Interessant, bisher bin ich immer davon ausgegangen dass ich per .00 in der Abweichung NTP von EIB sync unterscheiden könnte. Falsch wie sich jetzt herausstellt (es sei denn du hast EIB synchronisation auch konfiguriert ?).
Es ist zwar richtig dass beide Verfahren nur Sekundengenau sind aber ich bin davon ausgegangen dass EIB sync eine eigenentwickelung ist und dise deshalb nur die Sekunden betrachtet und Time eine fertige Lösung die die ticks synchronisiert. Damit ist zwar die eingehende Zeit nur sekkundengenau, aber die differenz kann ein Bruchteil sein.
Wenn Du auf deinem HS nur Time server parametriert hast, dann versteh ich dieses Verhalten allerdings auch nicht mehr :confused:
Gruss,
Gaston
Gaston, Du schrubst weiter oben dass Du die HS-Zeit stündlich per EIB synchronisierst, d.h. Du hast auf dem EIB einen vom HS unabhängigen Zeitgeber und Dein HS synct zusätzlich 1x täglich via TIME?
Gruss
Markus
Nein, ich synchronisiere ausschliesslich per EIB über meine DCF77 Jahresschaltuhr.
Die x.00 sind schon sehr merkwürdig.
Eigentlich nicht: x.yz = Internet x.00=EIB
Zumindest war das soweit meine Auffassung (sihe oben)
Gruss,
Gaston
Powered by vBulletin® Version 4.2.4 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.