There's multiple issues here, I'll take them collectively instead of inline:

a) You should not run ntpdate, instead you use the -q option to ntpd to handle any initial time steps.

b) All the delay/offset/jitter times are measured in ms, not seconds!

c) It seems that you have an ntp.drift file which contains "500"!

500 ppm is the maximum possible steering rate, and you get that value on your first query, which means that it must have been written to the drift file and picked up on startup.

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!

Can you run ntpd on the host machine and simply setup the client OS to be timesynced to the host?

Terje

Sander Smeenk wrote:
Hi,

I seek your help in strange timekeeping issues on Windows 2008r2 VMs
running on a Linux QEMU/KVM host. The clock drifts like a boat in a
storm at high sea and NTPD is giving me very very strange results.

The W32Time service (Windows' own 'NTP daemon') is switched off, as is
the Network Time Protocol service (ntpd.exe) when i run ntpdate.exe to
sync the clock:

| C:\Program Files (x86)\NTP\bin\>ntpdate.exe -b ntp4.bit.nl
| 21 Jan 09:54:53 ntpdate.exe[1600]: Raised to realtime priority class
| 21 Jan 09:54:53 ntpdate.exe[1600]: step time server ntp4.bit.nl offset 
1.213630 sec


Immediately thereafter i start the ntpd.exe service (see ntp.conf below)
and request 'lpeers' and 'rv' with ntpq:

| C:\Program Files (x86)\NTP\bin>ntpq -c lpe -c rv
|      remote           refid      st t when poll reach   delay   offset jitter
| ==============================================================================
|  ntp1.bit.nl     213.136.0.252    2 u    1   64    1    0.977   65.440 15.113
| *ntp2.bit.nl     213.136.0.252    2 u    1   64    1    0.977   65.727 14.817
|  ntp3.bit.nl     213.136.0.252    2 u    -   64    1    0.977   73.324 18.602
|  ntp4.bit.nl     .INIT.          16 u    -   64    0    0.000    0.000 0.977
| associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
| version="ntpd 4.2.8@1.3265-o Dec 22 13:27:17 (UTC+01:00) 2014  (2)",
| processor="x86", system="Windows", leap=00, stratum=3, precision=-10,
| rootdelay=1.221, rootdisp=8016.227, refid=253.226.115.248,
| reftime=d869e831.ae0cc93e  Wed, Jan 21 2015  9:56:17.679,
| clock=d869e834.bf56938a  Wed, Jan 21 2015  9:56:20.747, peer=8731, tc=6,
| mintc=3, offset=50.909860, frequency=500.000, sys_jitter=0.712723,
| clk_jitter=18.023, clk_wander=0.000


I was so quick the fourth server is still in .INIT. state but the other
servers immediately log 65+ seconds offset! The servers in ntp.conf have
iburst, so i wait a short moment and rerun ntpq:

| C:\Program Files (x86)\NTP\bin>ntpq -c lpe -c rv
|      remote           refid      st t when poll reach   delay   offset jitter
| ==============================================================================
| +ntp1.bit.nl     213.136.0.252    2 u   15   64    1    0.977  133.499 57.341
| +ntp2.bit.nl     213.136.0.252    2 u   13   64    1    0.977  152.764 67.567
| +ntp3.bit.nl     213.136.0.252    2 u   14   64    1    0.977  140.443 56.440
| *ntp4.bit.nl     .PPS.            1 u   11   64    1    0.977  168.788 59.501
| associd=0 status=0613 leap_none, sync_ntp, 1 event, spike_detect,
| version="ntpd 4.2.8@1.3265-o Dec 22 13:27:17 (UTC+01:00) 2014  (2)",
| processor="x86", system="Windows", leap=00, stratum=2, precision=-10,
| rootdelay=0.977, rootdisp=417.370, refid=172.2.53.81,
| reftime=d869e83f.afd782a8  Wed, Jan 21 2015  9:56:31.686,
| clock=d869e84a.9e0a4579  Wed, Jan 21 2015  9:56:42.617, peer=8733, tc=6,
| mintc=3, offset=67.515860, frequency=500.000, sys_jitter=59.501061,
| clk_jitter=17.852, clk_wander=0.000


All servers synced. A whopping 130+ seconds offset and inmense jitter.
Another short moment later:

| C:\Program Files (x86)\NTP\bin>ntpq -c lpe -c rv
|      remote           refid      st t when poll reach   delay   offset jitter
| ==============================================================================
| +ntp1.bit.nl     213.136.0.252    2 u    5   64    3    0.977  826.839 737.464
| +ntp2.bit.nl     213.136.0.252    2 u    5   64    3    0.977  826.946 725.080
| +ntp3.bit.nl     213.136.0.252    2 u    5   64    3    0.977  827.363 729.364
| *ntp4.bit.nl     .PPS.            1 u    1   64    3    0.977  893.712 769.845
| associd=0 status=0613 leap_none, sync_ntp, 1 event, spike_detect,
| version="ntpd 4.2.8@1.3265-o Dec 22 13:27:17 (UTC+01:00) 2014  (2)",
| processor="x86", system="Windows", leap=00, stratum=2, precision=-10,
| rootdelay=0.977, rootdisp=1727.849, refid=172.2.53.81,
| reftime=d869e879.b7859731  Wed, Jan 21 2015  9:57:29.716,
| clock=d869e87a.e685746d  Wed, Jan 21 2015  9:57:30.900, peer=8733, tc=6,
| mintc=3, offset=67.515860, frequency=500.000, sys_jitter=769.844946,
| clk_jitter=17.852, clk_wander=0.000

800+ seconds?!  What's going on!
Can someone explain why ntpd/ntpq logs these jittervalues and offsets?

I then stop the NTPD.exe service again, run ntpdate.exe against ntp4.bit.nl:

| C:\Program Files (x86)\NTP\bin>ntpdate.exe -b ntp4.bit.nl
| 21 Jan 09:59:20 ntpdate.exe[4796]: Raised to realtime priority class
| 21 Jan 09:59:28 ntpdate.exe[4796]: step time server 213.136.0.252 offset 
1.812400 sec

| C:\Program Files (x86)\NTP\bin>ntpdate.exe -b ntp4.bit.nl
| 21 Jan 10:00:56 ntpdate.exe[7316]: Raised to realtime priority class
| 21 Jan 10:01:02 ntpdate.exe[7316]: step time server 213.136.0.252 offset 
0.081487 sec


Also, when i run 'timeout 60' in a cmd.exe, even my human eye notices
the seconds aren't ticking at the same speed all the time. I'm no
Windows wizard, so i dont know how accurate 'timeout' is, but i would
expect to see a steady flow of seconds counting down?


Do any of you have experience with Win2k8R2 VMs on Linux QEMU/KVM hosts?
Any specific settings i might have overlooked?
Am i doing something terribly wrong?


ntp.conf on the Win2k8R2 servers:
| disable monitor
| server ntp1.bit.nl iburst
| server ntp2.bit.nl iburst
| server ntp3.bit.nl iburst
| server ntp4.bit.nl iburst prefer
| restrict default nomodify noquery nopeer notrap
| restrict -6 default nomodify noquery nopeer notrap
| restrict :: nomodify noquery nopeer notrap
| restrict 127.0.0.1
| restrict ::1
| driftfile "C:\Program Files (x86)\NTP\etc\ntp.drift"


Thanks in advance!

With regards,
-Sander Smeenk.



--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Reply via email to