Nick wrote:
Brian
thanks for your useful reply...
On Fri, 18 Jul 2014 02:03:48 +0000, Brian Inglis wrote:
Windows is using the MM timer as its high precision time source, not PM
timer, HPET or TSC.
Huh, I didn't know (and I doubt) that NTP uses the MM timer as time source.
Years ago there was a problem with NTP under Windows that the
interpolated system time used internally by ntpd got messed up when some
*other* program started to set the Windows MM timer to highest
resolution, e.g to play some multimedia stuff.
As a workaround I submitted a patch to ntpd which lets the NTP service
itself set the MM timer resolution high when it starts, so there are no
more other effects on the interpolated time when some other application
also does so.
The workaround comes in effect if the -M parameter is given on the
command line, and this is the default case for installations from the
Meinberg setup program.
Yes. I found the entry in the application log. I checked the old XP box
where ntp works well and that's using the MM timer.
This log message is just an information that the patch I've submitted
has set the MM timer resolution high. It does *not* affect the kind of
timer Windows has chosen to keep the system time.
This is always my sign that ntpd offset will diverge, and requires a
system restart, or more.
Huh?
Just stopping ntpd, removing the -M parameter, and starting the service
should have the same effect.
In Vista and newer the system time increments in 1 ms steps only
(instead in about 16 ms steps as in earlier versions), so newer versions
of ntpd don't even use interpolation if 1 ms steps are detected.
It would be a nice test to find out if the presence or absence of the -M
parameter makes a difference, and if timekeeping is affected if -M is
not used but some multimedia stuff is played.
Also when leap=11 that is the alarm state that says there are issues.
Does leap=11 mean the server is not sync'd?
This means your running ntpd could not (yet) synchronize to other time
sources.
Wait until reach is 377 on all sources and check again for leap=00.
I removed the -M from the service executable command and rebooted.
After 15 minutes I got this
C:\Users\nick>ntpq -pn
remote refid st t when poll reach delay offset
jitter
==============================================================================
-143.210.16.201 158.43.192.66 2 u 33 64 377 32.491 181.643
121.179
+85.119.80.233 110.116.250.33 3 u 29 64 377 29.461 59.626
88.079
+176.74.25.228 193.47.164.28 3 u 21 64 377 30.159 91.825
72.384
+176.74.25.227 193.11.166.8 2 u 32 64 377 30.065 20.692
117.706
+5.39.184.5 87.195.109.207 3 u 26 64 377 37.018 -3.686
138.898
94.228.220.14 .INIT. 16 u - 64 0 0.000 0.000
0.000
*130.88.212.143 193.62.22.90 2 u 36 64 377 37.078 62.566
93.284
C:\Users\nick>ntpq -c rv
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version="ntpd 4.2.7p450@1.2483-o Jul 17 7:20:46.78 (UTC+01:00) 2014 (1)",
processor="x86", system="Windows", leap=00, stratum=3, precision=-22,
rootdelay=46.020, rootdisp=139.381, refid=130.88.212.143,
reftime=d773f6dd.29fb24ea Fri, Jul 18 2014 20:41:17.163,
clock=d773f753.cf14ee36 Fri, Jul 18 2014 20:43:15.808, peer=40459, tc=6,
mintc=3, offset=67.250982, frequency=431.145, sys_jitter=54.722048,
clk_jitter=36.149, clk_wander=0.139
ntp.conf...
restrict default nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 ::1
driftfile "C:\Tools (x86)\NTP\etc\ntp.drift"
server 0.uk.pool.ntp.org iburst minpoll 6 maxpoll 6
server 1.uk.pool.ntp.org iburst minpoll 6 maxpoll 6
server 2.uk.pool.ntp.org iburst minpoll 6 maxpoll 6
server 3.uk.pool.ntp.org iburst minpoll 6 maxpoll 6
server 0.nl.pool.ntp.org iburst minpoll 6 maxpoll 6
server 1.nl.pool.ntp.org iburst minpoll 6 maxpoll 6
server ntp2d.mcc.ac.uk iburst minpoll 6 maxpoll 6
enable stats
statsdir "C:\Tools (x86)\NTP\etc\"
statistics loopstats
It's working! So the MM timer seems to mess up ntp on Win 7 but not on
XP.
Tried to explain above what the MM timer stuff is for.
Can you check what happens if you run any other application which sets
the MM timer high?
Previously if was sufficient to play some audio or video, or point your
web browser to a page containing multimedia content to mess up Windows
timekeeping again.
This performance is marginal for WSJTX. I need 10ms offset or less after
15 minutes.
I would like to have used the pool directive in ntp.conf but the
development versions don't seem to process it. (The Meinberg monitor
says unknown clock type.)
The Meinberg NTP monitor doesn't know this directive. Current versions
of the NTP package should support it, though.
To put it in perspective here's the performance I get on the same machine
when I boot Mint 17.
nick@mint17-01 ~ $ ntpq -pn
remote refid st t when poll reach delay offset
jitter
==============================================================================
-129.250.35.251 192.93.2.20 2 u 50 64 377 37.766 -0.413
22.384
+176.58.109.199 131.188.3.223 2 u 51 64 377 29.532 3.113
1.482
*178.79.160.57 130.133.1.10 2 u 48 64 377 29.074 2.984
1.994
-87.117.251.3 129.215.160.240 3 u 46 64 377 29.621 1.225
1.466
+130.88.212.143 193.62.22.90 2 u 42 64 377 37.233 1.904
1.187
nick@mint17-01 ~ $ ntpq -c rv associd=0
status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version="ntpd 4.2.6p5@1.2349-o Wed Oct 9 19:08:06 UTC 2013 (1)",
processor="x86_64", system="Linux/3.13.0-24-generic", leap=00, stratum=3,
precision=-23, rootdelay=31.652, rootdisp=59.450, refid=85.234.136.65,
reftime=d773f099.353d9b27 Fri, Jul 18 2014 20:14:33.207,
clock=d773f2b2.69839d3d Fri, Jul 18 2014 20:23:30.412, peer=14600, tc=6,
mintc=3, offset=1.095, frequency=-20.457, sys_jitter=1.518,
clk_jitter=0.703, clk_wander=0.101
This uses pool pool.uk.ntp.org and server ntp2d.mcc.ac.uk.
Is it possible to ever get the same level of performance on Windows 7?
Martin
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
