Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Wenn auf dem Router ein Linux läuft, kann man den inetd dazu bringen, auch das alte time protocol anzubieten. Aber das braucht man wirklich nur in Fällen, in denen man ganz alte Mühlen am Netz hat oder man aus irgendwelchen Gründen kein Firmware-Update beim HS machen kann. NTP ist jedenfalls zu bevorzugen.
Die Häufigkeit des Zeitabgleichs hat nichts mit dem Protokoll zu tun. Der HS verwendet, soweit ich das sehe, "richtiges" NTP, und gleicht einmal am Tag sowie beim Neustart die Systemzeit mit einem NTP-Server ab. Das reicht für normale Ansprüche aus, es sei denn, die RTC auf dem Mainboard ist total daneben. Aber das wäre ein Defekt, denn eine Quarzuhr sollte in 24 Stunden nicht merklich falsch gehen.
Wie gesagt: Der HS verwendet kein NTP sondern SNTP und gleicht nur periodisch die Zeit ab.
SNTP ist vom Packetaufbau gleich zu NTP aber es werden einige Variabeln im Paket die der Latenzkompensation in Bezugauf die genauigkeit dienen nicht verwendet (Client, sprich HS) oder auf 0 gesetzt (Server).
Ein SNTP client (HS) der sich an einem NTP Server synchronisiert ist kein problem, ein NTP client der sich an einem SNTP Server synchronisiert kann zu èProblemen führen.
also auch in der FW2.7 wie bisher. Danke für die Info
Das hängt von deiner Definition von "bisher" ab
In alten Firmwares (weis nicht mehr bis zu welcher) hat der HS das uralte time protocol verwendet.
In aktuellen Firmwares wird SNTP verwendet.
De3r unterschied ist nicht so sehr in der Genauigkeit wie darin dass es nun mit NTP servern funktioniert. Davor ging es nur mit servern die auch noch das time protokol anboten.
NTP mit kontinuirlichem time shifting wäre optimal da es da (Sommer/Witerzeit umschaltung ausgenommen) niemals einen Sprung rückwärts in der Zeit gibt was beim täglichen Stellen aber vorkommen kann.
Das muss ich mir mal genauer anschauen, aber ich habe den Verdacht, dass Gira einfach den Aufruf von rdate gegen ntpdate im cron ausgetauscht hat. Dafür spricht auch, dass man den Zeitpunkt der Synchronisierung in der Konfiguration einstellt. Warum man nicht einfach den ntpd verwendet, ist mir ehrlich gesagt nicht klar. Kann eigentlich nur sein, dass man damit bei Einwählverbindungen öfters einen Verbindungsaufbau provoziert.
Andererseits reicht es für den Einsatzzweck. Ob die Schaltuhr nun eine Sekunde früher oder später schaltet, dürfte kaum eine Rolle spielen. Wer die Zeit genauer auf dem Bus haben will, kann sich ja eine DCF77-Uhr reinhängen.
Andererseits reicht es für den Einsatzzweck. Ob die Schaltuhr nun eine Sekunde früher oder später schaltet, dürfte kaum eine Rolle spielen.
Das ist auch nicht der Punkt, das stimmt. Was ich nicht so toll finde ist dass zum Zeitpunkt der Umstellung ein Telegram X das vor Telegram Y im HS eingeht im Archiv dan u.U. in umgekehrter Reihenfolge auftauchen.
Und dies beschränkt sich nicht unbedingt auf 2 Telegramme, also
ABCDEFGHIJK könnte dann in der zeitlichen Reihenfolge ABEFGCHIDJK abgelegt werden. Ok, ist nur einmal pro Tag, aber auch bei einem Neustart. Hat man also ein Problem und startet den HS mehrmals neu und schaut dann für die Diagnose in den EIBMON kann das verwirrend sein oder gar zu falschen Schlüssen führen.
Ja, da hast Du recht, daran hab ich noch gar nicht gedacht. Dürfte aber wohl nur sehr selten auftreten. Dennoch wäre es bei einem Linux-System, wie es der HS ist, leicht vermeidbar. Aber ich glaube, da sind noch ganz andere Baustellen offen als das. Ich denke, wir werden ohnehin bald tiefgreifendere Änderungen am HS sehen, weil die Boards bei VIA nicht mehr im Programm sind. Wird Zeit für einen HS4...
... tut mir leid, wenn ich da ein Faß aufgemacht habe.
ich habe nur festgestellt, daß eben meine Uhren vom HS sowie die vom Asterisk-Server und die vom "normalen" Server nicht unbedingt synchron laufen. De Unterschied war zugegebenermassen gering ( 1-2 Minuten )
Jetzt war das Problem, daß ich verschiedene Schaltaktionen und zeitliche Begrenzungen laufen habe, welche nicht immer in der richtigen Reihenfolge ineinander greifen, obwohl ich die mit Minutenversatz programmmiert habe.
Das hat in der Tat zu unerwünschten Effekten geführt.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar