[ntp:questions] Timekeeping on Windows 2008r2 VM on Linux QEMU/KVM
nomail at example.com
Wed Jan 21 17:43:25 UTC 2015
Sander Smeenk <ssmeenk at freshdot.net> wrote:
> Quoting Terje Mathisen (terje.mathisen at tmsw.no):
>> 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.
The problem is that you give the clock an initial kick that ntpd does
not know about, and it tends to have problems correcting that.
This sometimes results in the problems you are seeing.
>> 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
Well, 60ms is not that bad for a Windows system, and 60s would be very
bad. So this actually makes a lot of difference.
>> 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.
Did you stop ntpd, then remove the file, then start ntpd again?
>> 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. :(
Maybe it is already doing that, and the interference between the
corrections by ntpd and by the VM host is the cause of the problem
you are seeing.
I know on VMware it works "OK", but for Windows that "OK" is never nearly
as good as for Linux. A Linux system will remain within a few ms, for
Windows 60ms is not bad at all.
Also not that on Linux, the more you poke it the more it starts to
misbehave. I think ntpd feeds correction data into the kernel that it
remembers in memory, but the kernel remembers it between boots.
So when you kill and restart ntpd a few times, the pictures of ntpd and
the kernel are very different, and ntpd starts to lose control of the
correction loop. Maybe it can happen in Windows as well.
So, don't restart ntpd more than once an hour or so when you are debugging.
By using ntpdate, you are aggrevating this problem.
More information about the questions