[ntp:questions] Timekeeping on Windows 2008r2 VM on Linux QEMU/KVM

Martin Burnicki martin.burnicki at meinberg.de
Thu Jan 22 09:12:08 UTC 2015


Sander Smeenk 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.

There's nothing wrong with using ntpdate, especially not under Windows

As already pointed out in some other posts here, ntpdate

- always steps the time if the -b option is used

- if the -b option is not used then it slews the time if the offset is 
below 128 ms, else it steps the time

- under Windows ntpdate is unable to slew the time (ntpd can, of 
course), so *have to* use the -b option

I think the discussion whether ntpdate should be used or not is 
worthless in this case. Maybe some of you remember the problems with the 
Windows multimedia timer, causing virtual time steps of the windows 
system time if set to highest resolution by some application *after* 
ntpd has been started.

As a workaround to avoid this ntpd for windows sets the MM timer to 
highest resolution by itself when the service starts (if the ntpd's -M 
option is used, which is the default when the Meinberg installer is used).

This usually causes the initial time seen by ntpd to be off by a couple 
of milliseconds anyway, since the virtual time step happens immediately. 
Anyway, after this the reported time offset should *decrease* down to 
some minimum, which depends on the target hardware, etc.

>> 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.

That's what I would expect. If the time offset doesn't settle you will 
probably have a new driftfile with a similar wrong huge drift value.


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany



More information about the questions mailing list