2

In my data centers, I have access to a stratum 1 server but I set up our servers to use ntp pool servers in addition to it. My main thinking was for backup in case our local server goes down but I am concerned this is actually causing time to be off more than it should be.

Based on the ntpq output below, ntpd is using my local stratum 1 server and two public servers ("+") which have a very bad delay in its calculation. We have had reports are time we have been putting into messages is off and I am thinking having these public servers involved is making the time sync worse, we are trying to have time accurate to within a millisecond.

Edit: The question I am looking for an answer on: is having these public ntp servers with high jitter making my accuracy of time worse compared to having my single local GPS data center ntp server (192.168.20.4) configured?

$ ntpq -pn
 remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.20.4    .TSYN.           1 u   18   64  377    0.799    0.626   0.028
+67.219.95.113   128.138.141.172  2 u    3  256  377   45.266   -0.664   4.542
-50.116.55.65    209.51.161.238   2 u   46  256  377    2.979    0.876   0.217
+74.117.214.2    .GPS.            1 u  235  256  377   83.977   -4.988   0.106
-205.233.73.201  198.82.247.71    3 u  218  256  175    9.369    1.712   0.236

$ ntpq -c rl
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version="ntpd 4.2.6p5@1.2349-o Sat Dec 20 19:00:16 UTC 2014 (1)",
processor="x86_64", system="Linux/2.6.32-431.11.2.el6.x86_64", leap=00,
stratum=2, precision=-24, rootdelay=0.934, rootdisp=5.188,
refid=192.168.20.4,
reftime=d8f8f71b.08d0821a  Sat, May  9 2015 17:14:03.034,
clock=d8f8f775.c8d11ec4  Sat, May  9 2015 17:15:33.784, peer=62815,
tc=10, mintc=3, offset=0.351, frequency=-16.428, sys_jitter=1.168,
clk_jitter=0.182, clk_wander=0.006
Improve this question
2

2 Answers 2

Reset to default
3

The NTP offsets you are seeing are milliseconds not seconds. If you have problems with the dates put in your e-mail headers being off, then it may be your clients. If you can get a copy of the headers, it should be easy to determine where the issue is. The Date: header should have almost exactly the same time as your the last Received: header (first MTA server to handle e-mail). NTP is far more accurate that is required for e-mail headers. If there is an issue, check that your servers are synchronized with your NTP server.

It appears you gathered this data relatively soon after restarting your NTP client. This is indicated by the poll vale of 256. It should rise to 1024 once things have stabilized.

Your NTP server is tracking your local server as noted by the "*" to the left. Given its stratum and jitter this is unlikely to change. If it where to report a time significantly different from the other servers, it might get evicted.

Two other servers are being used to determine if the current clock can be trusted. These are indicated by "+" to the left. They will be chosen from the lowest statum servers. The other two are not participating in voting as indicated by "-" to the left. The voting servers may shift over time based on their stability as a source for your server. The jitter of these servers should not cause you any issues, unless your local server gets evicted.

Improve this answer
1
  • The "Date:" header in an email is written out by the MUA (i.e. Outlook, Thunderbird) on the client PC before being sent to the SMTP server. Incorrect times in the "Date:" header indicate time issues on the client PC. Such as older Windows machines which do not have the correct Daylight Savings Time values and are off by one hour for part of the year.
    – tgharold
    Jun 14, 2015 at 13:13
0

NTP cannot achieve such precision in its jitter.

You should proably have a look at PTP instead.

http://en.wikipedia.org/wiki/PTPd

If you want redundancy, you could just get two GPS clocks.

A high jitter may be symptomatic of a congested (inter)network, or just a lack of some traffic shaping / reservation system. Make sure to pick a public NTP system that has a reasonably low, stable jitter, and tune your network to make this possible.

Improve this answer
3
  • NTP is capable of millisecond accuracy over uncongested symmetric network links. The jitter here isn't absurdly large so it's possible the OP could get there after a few days of stable measurements.
    – roaima
    May 10, 2015 at 14:22
  • 1
    Never provide only two time servers. Consider, if you have only two servers and one starts giving false time, how do your clients know which one is wrong? With only one server everyone remains consistent (even if that consistency is wrong). With more than two the voting algorithms will have a chance of correctly ignoring the false clock.
    – roaima
    May 10, 2015 at 14:24
  • Indeed, the rule for referencing time servers is "pick one or pick four-plus". That way if one of the four goes insane, you still have three servers which can be used to sanity-check each other. "A man with two clocks is never sure what time it is."
    – tgharold
    Jun 14, 2015 at 13:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.