NTP voll daneben

Hallo EFW-Gemeinde,

bin erst seit kurzem von IPCop auf EFW umgestiegen und muss mich erst noch eingewöhnen. Ein Problem habe ich aber, der Zeitserver ist extrem daneben mit seiner Zeit. Wenn ich ihn per Hand einstelle, geht er innerhalb eine Tages über 30 Minuten falsch.

Lese ich das richig, das NTP hier nicht mit einem externen NTP Server synchronisiert? :

Aug 18 03:11:00 ntpd ntpd exiting on signal 15
Aug 18 03:11:01 ntpd ntpd 4.2.0a@1.1190-r Wed Jan 9 14:21:28 EST 2008 (1)
Aug 18 03:11:01 ntpd precision = 141.000 usec
Aug 18 03:11:01 ntpd Listening on interface wildcard, 0.0.0.0#123
Aug 18 03:11:01 ntpd Listening on interface wildcard, ::#123
Aug 18 03:11:01 ntpd Listening on interface lo, 127.0.0.1#123
Aug 18 03:11:01 ntpd Listening on interface eth1, 1.1.1.1#123
Aug 18 03:11:01 ntpd Listening on interface br0, 192.168.11.1#123
Aug 18 03:11:01 ntpd Listening on interface ppp0, 93.104.120.180#123
Aug 18 03:11:01 ntpd kernel time sync status 0040
Aug 18 03:11:06 ntpd frequency initialized 0.000 PPM from /var/lib/ntp/drift
Aug 18 03:14:23 ntpd synchronized to LOCAL(0), stratum 10
Aug 18 03:14:23 ntpd kernel time sync disabled 0041
Aug 18 03:15:28 ntpd kernel time sync enabled 0001

Woran könnte das liegen? Habe auch schon testweise mal einen override eingegeben (pool.ntp.org), half bis jetzt aber auch nichts.

EFW Community 2.2 läuft in einer VM auf Windows Server 2008 mit Hyper-V Role enabled. Ich weiss, ist nicht der Sinn der Sache, aber so kann ich erst mal alles in Ruhe testen.

Freue mich über jede Anregung

Hmm, nun passt es zur Zeit. Seltsam... nichts geändert (kam noch nicht dazu mich weiter drum zu kümmern) und nun synchronisiert er fleißig und alle Rechner sind korrekt eingestellt.

Aug 25 01:27:50 ntpd time reset +0.153384 s
Aug 25 01:32:11 ntpd synchronized to LOCAL(0), stratum 10
Aug 25 01:33:16 ntpd synchronized to 85.214.123.101, stratum 2
Aug 25 02:00:08 ntpd time reset -0.161328 s
Aug 25 02:04:26 ntpd synchronized to LOCAL(0), stratum 10
Aug 25 02:06:35 ntpd synchronized to 85.214.123.101, stratum 2
Aug 25 04:24:40 ntpd time reset +0.154235 s
Aug 25 04:28:58 ntpd synchronized to 85.214.123.101, stratum 2
Aug 25 05:33:11 ntpd time reset -0.208181 s
Aug 25 05:37:32 ntpd synchronized to 85.214.123.101, stratum 2
Aug 25 07:18:02 ntpd time reset +0.193131 s
Aug 25 07:22:22 ntpd synchronized to LOCAL(0), stratum 10
Aug 25 07:23:27 ntpd synchronized to 85.214.123.101, stratum 2
Aug 25 08:06:09 ntpd time reset -0.129086 s
Aug 25 08:10:27 ntpd synchronized to LOCAL(0), stratum 10
Aug 25 08:12:33 ntpd synchronized to 85.214.123.101, stratum 2
Aug 25 09:30:50 ntpd time reset -0.177973 s
Aug 25 09:35:08 ntpd synchronized to LOCAL(0), stratum 10
Aug 25 09:36:14 ntpd synchronized to 85.214.123.101, stratum 2

Hat jemand eine Idee zur Ursache? Also natürlich warum es vorher nicht lief?

Habe mich lange nicht um das immer noch vorhandene Problem gekümmert, aber die ständigen Zeitsprünge machen doch das Lesen von protokollen fast unmöglich. Habe nun den Verdacht, das neben der NTP synchronisierung noch etwas anderes die Systemzeit zu ändern scheint (TimeSync vom Parent ist ausgeschaltet).
Nun würde ich gerne den efw NTP-Dienst testweise ausschalten, kann mir jemand sagen, wo und wie ich das mache?

Ja, das Zeit- und Timing-Problem mit VMs hab ich an anderer Stelle schon erfahren müssen. Ich wollte auch Endian keine Schuld zuschieben, ich suche nur grad nach der geschicktesten Lösung :ugeek:
Mir ist allerdings noch nicht ganz klar, woher Endian noch seine Zeit bezieht, außer vom NTP Client. Ich habe bisher noch keine Integrationsdienste laufen (hat jemand zufällig mal die Hyper-V Integration Services in Endian eingebunden? Wenn ja, wie?), ergo müsste doch Endian der einzige Zeitlieferant sein, oder nicht? Wie ist das denn auf einem physikalischen System? Bios-Uhr?