4

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?

Alex I
  • 207
  • 1
  • 8
  • 2
    How long has `ntpd` been running? It looks from your stats like it hasn't had a chance to synchronize anything yet. Give it 24 hours and then check back. – David Schwartz Mar 01 '13 at 09:08
  • 1
    Your reach is terrible; wait till it tops off at 377. – Martin Schröder Mar 04 '13 at 23:37
  • @MartinSchröder: I had left this running for a few days, reach topped off, otherwise no improvement, actually offset went up to -300. I would still like to know how to force a step if the offset is above a certain threshold. – Alex I Mar 09 '13 at 00:23
  • P.S. Could anyone explain why the long-term average of the offset wouldn't be zero? – Alex I Mar 09 '13 at 00:24
  • I agree that this is strange. I just noticed it on a fresh Windows Server 2012 R2 (which is based on Windows 8.1, which provides ways of getting very precise timestamps through the API). The same machine with the previous installation would synchronize immediately (I would practivally start the machine, and the next thing I'd see would be offset in the range of `0.050 ms`). This time, I started it and it took the entire night to reduce the offset from `100ms` to zero. It synchronizes with stratum 1 servers on the same network (latencies are in microseconds). – vgru Sep 23 '17 at 07:34
  • That's, as you noted, especially strange, because ntp status constantly reports the "correct" offset, meaning it understands that the clock needs correcting. I have a feeling like the `ntpd` service is unable to correct the clock, because the synchronization behaves similarly to the Windows' crappy sync algorithm (but `Windows Time` service is disabled on my machine, and there are no errors in the event log). – vgru Sep 23 '17 at 07:38

2 Answers2

5

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.

Chris S
  • 77,945
  • 11
  • 124
  • 216
4

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:

  1. Not using iburst on every single server
  2. Picking your best server, using iburst on that and marking it with prefer, i.e. "server tick.example.com iburst prefer".
  3. Only hand-picking 3 close servers.
  4. More use of the regional pool DNS names (such as [0-3].us.poo.ntp.org) for the rest.
  5. Shoot for at least 4 total reference servers, but no more then 9.
  6. 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".

tgharold
  • 609
  • 8
  • 19