Ntpd excessively inaccurate
I have ntpd set up (Meinberg ntp-4.2.6p5@london version for Windows on a Windows 7 client) with a bunch of nearby servers selected for low ping times (usually 10-20ms ping). However it seems my clock is only accurate to within 100ms or less, and it doesn't get better over time. I would have thought it can get a lot more accurate than the ping time, this is disappointing. How to make it work better?
ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
+pool-test.ntp.o 216.218.254.202 2 u 259 1024 17 12.920 -106.39 111.972
+palpatine.steve 208.201.242.2 3 u 239 1024 17 16.959 -102.84 112.056
+grom.polpo.org 127.67.113.92 2 u 259 1024 17 17.362 -184.43 74.468
+paladin.latt.ne 204.123.2.72 2 u 378 1024 3 24.211 -106.97 61.825
+public-ntp1.iso 204.13.164.164 3 u 259 1024 17 33.080 -100.17 65.970
+nist1.symmetric .ACTS. 1 u 214 1024 17 17.548 -108.30 111.951
*nist1-sj.ustimi .ACTS. 1 u 245 1024 17 21.826 -111.02 63.313
How can jitter and offset be so much greater than delay? Being off by 100ms when the ping time is 12ms seems ridiculous, am I reading this wrong?
In fact, I am not sure ntp is doing anything to change my clock - it appears to get a time but not necessarily set anything. How can I check?
A few more bits of info:
ntpdc> sysinfo
system peer: nist1-sj.ustiming.org
system peer mode: client
leap indicator: 00
stratum: 2
precision: -11
root distance: 0.02182 s
root dispersion: 0.15431 s
reference ID: [216.171.124.36]
reference time: d4dae2b5.3c32ce54 Fri, Mar 1 2013 0:17:57.235
system flags: auth monitor ntp kernel stats
jitter: 0.045776 s
stability: 0.000 ppm
broadcastdelay: 0.000000 s
authdelay: 0.000000 s
more "c:\Program Files (x86)\NTP\etc\ntp.drift"
192.049
more "c:\Program Files (x86)\NTP\etc\ntp.conf"
driftfile "C:\Program Files (x86)\NTP\etc\ntp.drift"
server nist1.symmetricom.com iburst
server nist1-sj.ustiming.org iburst
server 149.20.68.17 iburst
server 173.230.144.109 iburst
server 65.19.178.219 iburst
server 204.2.134.162 iburst
server 173.230.144.109 iburst
server 207.115.64.229 iburst
Ideally I want a time that is no more than 50ms away from the median of the configured servers, if it ever gets further away I want it to step. Is there any config option that I can set that would make ntp do that?
Solution 1:
Jitter (a.k.a. dispersion in older NTP) can and will vary a lot over time. Especially if you have a setup where the connection between you and the NTP server is congested. You will need to either run "ntpq -p" frequently (about every "poll" seconds) to monitor jitter, or turn on the performance file ("statsdir" and "statistics" lines in the ntp.conf file).
http://www.ntp.org/ntpfaq/NTP-s-sw-clocks-quality.htm http://www.ntp.org/ntpfaq/NTP-s-trouble.htm
Ideally I want a time that is no more than 50ms away from the median of the configured servers, if it ever gets further away I want it to step. Is there any config option that I can set that would make ntp do that?
NTP does not work that way. It picks one server from your list, marks it with '*' (asterisk, a.k.a. reference time source) in the first column of the 'ntpq -p' output and attempts to follow it. In the case where the reference time source has become unreachable, it will fall back to following one of the '+' (qualified candidates) servers.
I suggest:
- Not using iburst on every single server
- Picking your best server, using iburst on that and marking it with prefer, i.e. "server tick.example.com iburst prefer".
- Only hand-picking 3 close servers.
- More use of the regional pool DNS names (such as [0-3].us.poo.ntp.org) for the rest.
- Shoot for at least 4 total reference servers, but no more then 9.
- Never configure a "server 127.127.1.0" (a.k.a. local clock) or "fudge" line.
By default the "slew" vs "step" choice is 128ms. If the time offset is > 128ms, it will step instead of slew. See the "-x" paramenter of "ntpd" (which should never be used unless you have software that freaks out if the clock is stepped).
In addition to "ntpq -p" you may also want to look at "ntpdc -c loopinfo".
Solution 2:
NTP was designed to get accurate time within 1s, on almost any network. So in that regard 100ms is functioning correctly. In actual use today NTP usually keeps time within 20ms on almost any hardware, and 5-10ms on hardware with a steady RTC.
If your server is continuously off by consistent numbers (compared to it's peers) then it likely has a lot of jitter in its RTC. NTP could compensate for this by pounding it's peers to constantly get the "right" time. However, this isn't recommended, and isn't very courteous to those you're peering with.
NTP doesn't "set" the clock (by default). It "slews" the clock, making it run a little faster or slower until the clock hits a target time. The slew rate is then readjusted to compensate for "drift" (the amount NTP has calculated the RTC to be fast or slow as compared to the peers).
Also, I agree with all of tgharold's Answer's recommendations.