Hi, Gibt es eine Möglichkeit einen Windowsserver als NTP-Server laufen zu lassen, so dass er nicht nur auf NTP Requests antwortet sondern auch nach einer einstellbaren Zeit einen Broadcast mit der aktuellen Zeit aussendet? mfg
NTP geht immer vom Clienten an den Server (Server! Er bedient Anfragen). Das ganze andersrum, das hat Microsoft mal mit Internetseiten versucht: Man nannte es "Server-Push"; der Server sollte dem Clienten ne Seite aufs Auge drücken. Hat sich gottseidank aber nicht durchgesetzt. Kram mal den ganzen Gruppenrichtlinien-Müll raus, irgendwo kann man die Rechner synchronisieren. Ob das dann per NTP läuft oder über irgendein MS-Protokoll weiß ich net, aber funktionieren tut es.
Bei dieser Anwendung sollen ~800 Teilnehmer synchronisiert werden. Diese Anwendung wurde auch schon mit einem Linux Rechner realisiert, doch ich würde einen Windows Rechner bevorzugen. Die Wahl mit einem Broadcast zu arbeiten ist dadurch begründet, dass anstelle von 800 Requests und anschließenden 800 Replies nur 1 Broadcast benötigt wird.
Hu, langsam. Broadcast geht über UDP. Ob das Päckchen dann auch überall ankommt, weißt du dann immer noch net. Und 800 Anfragen, das is doch garnix? Frag mal die Betrieber von ptb, was die so in der Sekunde abhandeln...
Es spielt aber keine Rolle ob die überall sicher ankommen, denn sie werden regelmässig verschickt.
Dann kannste die doch gleich ganz normal als Clienten konfigurieren... ich verstehs Problem net.
Die Clients sind Geräte welche aus µC + enc28j60 bestehen. Sie können zwar auch requests senden, ist aber nicht erwünscht (Aufgabenstellung). => FRAGE: Gibt es eine Möglichkeit einen Windowsserver als NTP-Server laufen zu lassen, so dass er nicht nur auf NTP Requests antwortet sondern auch nach einer einstellbaren Zeit einen Broadcast mit der aktuellen Zeit aussendet?
Wenn's mit der jetzigen Lösung leichter geht und schon zuverlässig funktioniert, wieso lässt du's nicht einfach so? Never change a running System!
Bis jetzt funktioniert es mit einem Linux Server, wobei das jedoch nicht der Aufgabenstellung entspricht sondern nur zur Überprüfung der selbsterstellten Software des µC dient. In dem Netzwerk in welchem diese Geräte später untergebracht werden steht schon ein Windows server. Suche nach NTP-Broadcast für Windowsserver. aber mal zwischendurch auch Danke für die vielen raschen antworten.
Hauatie R. wrote: > Gibt es eine Möglichkeit einen Windowsserver als NTP-Server laufen zu > lassen, so dass er nicht nur auf NTP Requests antwortet sondern auch > nach einer einstellbaren Zeit einen Broadcast mit der aktuellen Zeit > aussendet? Nach bestem Wissen und Gewissen: Nein.
Es gibt NTP-Server für Windows, die Broadcasts unterstützen. Hier kann man einen Win32-Port des offiziellen NTP-Servers von www.ntp.org herunterladen: http://www.meinberg.de/english/sw/ntp.htm#ntp_nt_stable Und im "ntp cheat sheet" (http://www.meinberg.de/download/ntp/docs/ntp_cheat_sheet.pdf) wird erwähnt, wie man Broadcasts/Multicasts aktiviert.
normalerweise NTP ja die Netzwerklaufzeit mit raus. Das ganze geht ja dann bei UTP nicht mehr. Also wenn es über UTP dann ist es kein richtiges NTP mehr. Aber ich seh noch kein Problem wenn sich 800 Clients aller 5min die aktuelle Zeit hohlen (so lange sollte sie schon recht genau gehen). Das sind dann weniger als 3abfrage pro sekunde, das sollte auch ein alter P90 noch schaffen. (man muss bloss dafür sorgen das die Client es nicht immer Gleichzeitig machen)
>>Bei dieser Anwendung sollen ~800 Teilnehmer synchronisiert werden. Diese
Anwendung wurde auch schon mit einem Linux Rechner realisiert, doch ich
würde einen Windows Rechner bevorzugen. Die Wahl mit einem Broadcast zu
arbeiten ist dadurch begründet, dass anstelle von 800 Requests und
anschließenden 800 Replies nur 1 Broadcast benötigt wird.
Hi 800 Rechner, da stößt du doch an die Grenze von Windows. Kann dein
Windows überhaupt soweit zählen ohne dabei ne Fehlermeldung zu bringen??
;-))
Außerdem warum willst du das per broadcast machen? einmal beim
hochfahren reicht völlig aus.
nachtrag: Sind die 800 Clients überhaupt in einem subnetz? Wenn nicht wird es es schwer mit UTP über router hinweg.
Peter wrote: > normalerweise NTP ja die Netzwerklaufzeit mit raus. Das ganze geht ja > dann bei UTP nicht mehr. Also wenn es über UTP dann ist es kein > richtiges NTP mehr. NTP arbeitet praktisch immer mit UDP, mit oder ohne Broadcasts. Insbesondere für die NTP-Server im Internet (wie PTB) wäre TCP sehr viel belastender als UDP. Laufzeitanalyse geht damit trotzdem.
Sebastian wrote: > Außerdem warum willst du das per broadcast machen? einmal beim > hochfahren reicht völlig aus. Du gehst davon aus, dass alle 800 Rechner täglich frisch gestartet werden. Das ist in Firmen nicht generell der Fall, erst recht nicht wenn Server darunter sind.
ntp sieht beides vor, aber wie soll dann ohne eine bidirektionale Kommunikation die Netzlaufzeit rausgerechnet werden? Dann kommt noch dazu das jeder eine Broadcast abschicken kann und damit das ganze netz umstellt - das würde ich schon als Sicherheitslücke sehen.
Peter wrote: > ntp sieht beides vor, aber wie soll dann ohne eine bidirektionale > Kommunikation die Netzlaufzeit rausgerechnet werden? Dass eine rein passive also unidirektionale Reaktion auf Broadcasts keine Laufzeitkorrektur vornehmen kann ist klar. Aber UDP ist nicht gleichbedeutend mit unidirektionaler Kommnunikation. Das übliche netzübergreifende NTP arbeitet mit UDP ohne Broadcasts, aber eben nicht nur in eine Richtung, sondern mit Frage/Antwort. Daher ist eine Laufzeitkorrektur möglich. Ein Broadcast-Mode ist in NTP ausdrücklich vorgesehen, und die Laufzeit wird dann auch nicht eingerechnet. Da Broadcast-Medien üblicherweise sehr kurze Latenzzeiten haben, spielt dass dann aber auch keine Rolle.
Die Geräte können keine Broadcasts machen (softwaretechnisch nicht möglich) Sie sollen bei korrekter Funktion einmal gestartet werden und nie mehr abgeschaltet werden (Monitoring verschiedenster Sensoren). Probiere gerade diese Software auf die Rufus t. Firefly verlinkt hat. Sie funktioniert so wie ich mir das vorgestellt habe nur habe ich noch ein paar kleine Konfigurationsprobleme welche aber mit genügend Zeit sicher noch gelöst werden können. Danke nochmals für diese Hilfe.
Das Projekt klingt ganz interesannt und ich (andere bestimmt) auch würden uns dann mal über ein paar Bilder,zahlen und fakten freuen 800 µC im Netzwerk.......
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.