gooly writes: > Am 13.09.2014 23:47, schrieb David Woolley: > > On 13/09/14 15:51, gooly wrote: > >> And this would not explain why ntp.drift is not created?
On some systems (as I recall), a non-existent drift file will not be created - you might try creating an empty one and seeing what happens. If you run at debug level 1, you should also see messages about the drift file update process. > > It's not created because synchronisation has never been acquired. The > > lack of ntp.drift is a secondary effect. > > ok - but why the "synchronisation has never been acquired"? run 'ntpq -p' and see what happens. You'll want to see a non-zero "reach" and values other than 0 for various other things. > And what do I have to do so that not only at (re-) start ntp sets the > time of the vps? ntpd should do this for you, especially if you start it with the -g option. > I don't see any error message and no notice that e.g. a try to change > the time failed - the event reader (eventvwr) shows only that ntp has > been started correctly? > > The time difference increases ~7 sec. every 15 minutes. If yuor system is *slowing* by 7 sec every 15 minutes, I suspect you are losing clock interrupts. At that rate ntpd will never be able to keep your clock sync'd. > PS: may be this helps? > > C:\Windows\System32>ntpq -p > > remote refid st t when poll reach delay offset jit > ter > > =========================================================================== > === > > janetzki.eu 5.9.80.113 3 u 66 64 377 9.893 251511. 2370 > .61 > > net2.uni-paderb .DCF. 1 u 12 64 377 18.546 251914. 2338 > .44 > > 2a01:4f8:110:51 178.63.61.67 3 u 34 64 377 10.463 251768. 2344 > .13 > > 16-164-ftth.ons 193.67.79.202 2 u 60 64 377 21.001 251558. 2356 > .75 > > y.ns.gin.ntt.ne 145.238.203.14 2 u 62 64 377 20.690 251544. 2374 > .56 > > ts2.aco.net .PPS. 1 u 57 64 377 16.820 251589. 2379 > .13 > > ts1.univie.ac.a .PPS. 1 u 10 64 377 17.828 251940. 2333 > .10 > > mail.somenet.or 217.19.37.27 2 u 46 64 377 16.373 251679. 2382 > .17 > > palmers.nobody. 193.171.23.163 2 u 29 64 377 17.824 251802. 2323 > .55 > > cl-2008.mbx-01. 195.58.160.5 3 u 5 64 377 37.461 251981. 2372 > .91 > > trust.nobody.at 131.130.251.107 2 u 61 64 377 19.276 251548. 2361 > .68 > > 2001:a60::123:1 212.18.1.106 2 u 24 64 377 12.096 251845. 2337 > .77 > > ptbtime1.ptb.de .PTB. 1 u 16 64 377 17.064 251890. 2327 > .26 > > ptbtime2.ptb.de .PTB. 1 u 8 64 377 16.556 251957. 2364 > .28 > > ptbtime3.ptb.de .PTB. 1 u 38 64 377 65.845 251757. 2411 > .84 > > foxtrot.zq1.de 235.106.237.243 3 u 61 64 377 9.426 251546. 2364 > .88 > > ntps1-0.eecsit. .PPS. 1 u 12 64 377 17.605 251919. 2347 > .01 > > time.fu-berlin. .PPS. 1 u 63 64 377 17.566 251534. 2357 > .45 > > ns2.probe-netwo 131.188.3.221 2 u 13 64 377 5.397 251915. 2360 > .15 > > zeit.fu-berlin. .PPS. 1 u 27 64 377 18.060 251823. 2351 > .31 > > and > > C:\Windows\System32>ntpq -crv > > associd=0 status=c018 leap_alarm, sync_unspec, 1 event, no_sys_peer, > > version="ntpd [email protected] Jul 30 11:55:08 (UTC+02:00) 2012 (2)", > > processor="x86", system="Windows", leap=11, stratum=4, precision=-21, > > rootdelay=30.116, rootdisp=2726.363, refid=5.9.67.110, > > reftime=d7bf26ea.de20f8a0 Sat, Sep 13 2014 22:26:18.867, > > clock=d7bf9c38.52662d5e Sun, Sep 14 2014 6:46:48.321, peer=0, tc=6, > > mintc=3, offset=0.000, frequency=500.000, sys_jitter=0.000, > > clk_jitter=0.000, clk_wander=0.143 The frequency of 500ppm indicates ntpd has "hit its limit" of how much adjusting it can do. leap=11 means ntpd is not synchronized. The first thing to fix is the problem with clock frequency. H _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
