Quoting Terje Mathisen ([email protected]): > a) You should not run ntpdate, instead you use the -q option to ntpd to > handle any initial time steps.
What is actually wrong with running ntpdate to initially sync a clock? Why is the ntpdate.exe binary provided when 'we' shouldnt use it? Keep in mind that i 'just want to get to seconds accuracy' before i start ntpd. > b) All the delay/offset/jitter times are measured in ms, not seconds! I actually knew that. I made that mistake on this list before. However it is also not relevant to the issues i am experiencing. Wether it's microseconds or seconds, the jumps in offset/jitter are abnormal nonetheless. > c) It seems that you have an ntp.drift file which contains "500"! Indeed i did. That file was probably written by ntpd after the first run going completely haywire. I removed it from the configuration. No change to the issues i'm experiencing. > d) I suspect that the QEMU/KVM virtualization of the Windows > environment is faulty, i.e. the baseline frequency of your emulated > hardware is badly wrong! Wouldn't you expect to see the same issues on other VMs running on that particular hypervisor host then? > Can you run ntpd on the host machine and simply setup the client OS to > be timesynced to the host? I guess not. Linux VMs dont essentially need to run ntp to keep their time synced if they use the correct clock source (kvm_clock) and the host is properly configured, but i would have no clue if Windows is able to do such stuff, let alone how. :( -Sndr. -- | Always try to be modest, and be proud of it! | 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7 FBD6 F3A9 9442 20CC 6CD2 _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
