NTP root dispersion

tony359 · 10-05-2013, 04:31 PM

Hi there,

I have a Linux server which should sync on a Windows NTP. I've read everywhere that this is a bad thing, but I cannot change it.

The Linux NTP refuses to sync because - I found out - the root dispersion of the Windows server is way off.

Is there a way to tell the Linux NTP daemon to just ignore it and sync anyway?

This is the data:

Code:

ntpq> o
     remote           local      st t when poll reach   delay   offset    disp
==============================================================================
 10.55.85.10     10.55.85.20      2 u   62   64  377    0.977  1186.41  17.461

ntpq> as
ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 37270  9014   yes   yes  none    reject   reachable  1

ntpq> rv 37270
assID=37270 status=9014 reach, conf, 1 event, event_reach,
srcadr=10.55.85.10, srcport=123, dstadr=10.55.85.20, dstport=123,
leap=00, stratum=2, precision=-6, rootdelay=0.000,
rootdispersion=10795.898, refid=43.194.158.5, reach=377, unreach=0,
hmode=3, pmode=4, hpoll=6, ppoll=6, flash=400 peer_dist, keyid=0, ttl=0,
offset=1233.183, delay=0.977, dispersion=17.477, jitter=221.590,
reftime=d5f96f89.8d206c87  Fri, Oct  4 2013 17:47:05.551,
org=d5fa76e3.e1183b60  Sat, Oct  5 2013 12:30:43.879,
rec=d5fa76e2.a56936e6  Sat, Oct  5 2013 12:30:42.646,
xmt=d5fa76e2.a5637de9  Sat, Oct  5 2013 12:30:42.646,
filtdelay=     0.98    0.98    0.98    0.98    0.98    4.93    0.98    0.98,
filtoffset= 1233.18 1186.41 1117.35 1071.55 1012.90  976.23  939.96  914.66,
filtdisp=     16.60   17.59   18.54   19.51   20.49   21.43   22.41   23.37

Thanks!

TB0ne · 10-06-2013, 10:34 AM

Quote:

Originally Posted by tony359

Hi there,
I have a Linux server which should sync on a Windows NTP. I've read everywhere that this is a bad thing, but I cannot change it.

If you're the Linux administrator, you sure can. Set up your Linux system to use pool.ntp.org servers (http://www.pool.ntp.org/en/). If you've got a route out to the Internet (even through a proxy server), that'll be FAR better than that Windows server, which is having issues. You also have another option, and that is to use a cheap (less than $100 USD) USB GPS receiver. It's easy to set up NTP to use a generic NMEA source, and I have a tutorial posted on this site on how to do it. That'll get you a VERY accurate stratum 1 clock.

Quote:

The Linux NTP refuses to sync because - I found out - the root dispersion of the Windows server is way off. Is there a way to tell the Linux NTP daemon to just ignore it and sync anyway?

It's a bad idea to ignore errors. The first step I'd take would be to fix the Windows server. The NTP source is just stepping back and forth too much, and eventually just gives up. Barring that, you CAN lower the maximum distance allowed from to force rejection at a lower threshold. Check out the NTP docs for some various tricks:
http://www.ntp.org/ntpfaq/NTP-s-conf...ks.htm#AEN4252

Again, though...you MIGHT be able to get things 'fooled' into working, but things will be unstable. The clock is still likely to drift/fail. Use a stable trusted source.

tony359 · 10-06-2013, 01:24 PM

HI,

Thanks for your reply.

Unfortunately I cannot use other NTPs and I do not have internet access on that server. I cannot touch the Windows NTP either. I know it's not good, but this is my scenario.

I'll check the documents you are suggesting and I'll come back with more questions!

Thanks
Tony

TB0ne · 10-06-2013, 02:50 PM

Quote:

Originally Posted by tony359

HI,
Thanks for your reply.

Unfortunately I cannot use other NTPs and I do not have internet access on that server.

How do you load patches and other things? Even if you have a proxy server, you can still access the public NTP pools.

Quote:

I cannot touch the Windows NTP either. I know it's not good, but this is my scenario.

That makes the problem even easier to solve...tell your Windows admins to get crackin'.

Quote:

I'll check the documents you are suggesting and I'll come back with more questions!

No worries...you MIGHT find something to help you in there, but the options are many, and there's no real easy way to test, other than stopping/starting things over and over.

tony359 · 10-06-2013, 02:56 PM

It's a multimedia server I won't manage it, I just run updates coming from the manufacturer every now and then. Long story.

I am trying to find out why the windows time server is off. It's sync'd to the system clock, somehow is not syncing to the NTP server anymore. I guess as soon as its root dispersion is less than 1000ms my Linux server should start trusting the W32 time server again!

I had a look at that page but there are only 3 scenarios which they don't seem relevant to my case. Is that the correct link?

Ta
Tony

TB0ne · 10-06-2013, 03:28 PM

Quote:

Originally Posted by tony359

It's a multimedia server I won't manage it, I just run updates coming from the manufacturer every now and then. Long story.

Been there, and I understand what you mean. However, one firewall exception for stateless UDP connection to the time pools shouldn't pose a problem for their systems/security, and let things run better. Just a suggestion.

Quote:

I am trying to find out why the windows time server is off. It's sync'd to the system clock, somehow is not syncing to the NTP server anymore. I guess as soon as its root dispersion is less than 1000ms my Linux server should start trusting the W32 time server again!

You said it yourself...it's sync'ed to the system clock. They drift, especially on Windows systems. You can essentially 'force' NTP to use the system clock as a reference source (the 'fudge' setting), but you play with fire. It'll jitter wildly, and you'll never get a decent time lock, as you've seen.

Quote:

I had a look at that page but there are only 3 scenarios which they don't seem relevant to my case. Is that the correct link?

Yes, but those are only EXAMPLES...the documentation you can page through there explains everything. Honestly, though...until the actual problem is fixed upstream, there's only so much you can do.

tony359 · 10-06-2013, 03:44 PM

Got it, I thought I was finding a relevant case on that page.

I agree with you, I'm dealing with the relevant people to see if the Windows time server can be fixed - found that the external NTP they use was going up and down!

Once the windows time server is stable I can see if the Linux NTP trusts it.

A question: what exactly is the root dispersion? I've read several descriptions but still fail to understand exactly the meaning.

Thank you very much for your help, it's greatly appreciated.

Tony

TB0ne · 10-06-2013, 04:13 PM

Quote:

Originally Posted by tony359

Got it, I thought I was finding a relevant case on that page.

I agree with you, I'm dealing with the relevant people to see if the Windows time server can be fixed - found that the external NTP they use was going up and down! Once the windows time server is stable I can see if the Linux NTP trusts it.

That will certainly help, but Windows and time-services can often be challenging. Having it USE an external time source is easy...having Windows BE the authoritative time source is another matter.

Quote:

A question: what exactly is the root dispersion? I've read several descriptions but still fail to understand exactly the meaning.

Essentially, it's the maximum error (difference), between the local clock as it relates to the reference clock. Since your upstream server is reporting a HUGE difference, the Linux NTP daemon is smart enough to know not to trust it.

tony359 · 10-06-2013, 04:22 PM

So say the root dispersion is 7s on the windows server, that means that the Windows time server last time it checked itself against the external NTP found it was 7 seconds off?

jpollard · 10-09-2013, 08:00 AM

You can force ntpd to sync no matter what ( see the man page on ntpd and look at the -g option).

something that may still cause you problems is that Windows doesn't fully implement the NTP protocol... Most of it, yes, but not all.

tony359 · 10-09-2013, 01:16 PM

Hi,

The -g parameter will set the clock no matter how much it's off, but will it trust a free-running NTP?

jpollard · 10-09-2013, 02:29 PM

Quote:

Originally Posted by tony359

Hi,

The -g parameter will set the clock no matter how much it's off, but will it trust a free-running NTP?

yes. The "trust" is not due to how much it is off, just the fact that the adjtime system call doesn't allow for more than around 15 minutes difference between the existing time, and the NTP server. This is because making LARGE jumps causes accounting failures, and can cause filesystem issues (files created in the future...). The use of the -g option is only usable when ntpd is first started, with the assumption that it is during system boot when accounting is focused on only system overhead. Once the daemon is active, and boot enters multiuser mode then, and only then is accounting tracking users, and then it needs to be consistent.

tony359 · 10-09-2013, 03:20 PM

Thanks.

Slightly OT question.

If I restart the NTP service, under the list of processes I get:

Code:

/etc# ps -ef | grep ntpd
ntp       8527     1  0 21:12 ?        00:00:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -u 105:110 -x
root     22016  7628  0 21:17 pts/0    00:00:00 grep ntpd

How can I tell the deamon to start with the -g parameter?
Thanks

michaelk · 10-09-2013, 03:35 PM

What distribution/version are you running?

Depends on the version of ntp. The original method was to call ntpdate prior to starting ntp. This does the same thing as the -g option. Take a look at your ntp start up script to see if it runs nptdate. If so, then no changes are required.

tony359 · 10-09-2013, 03:45 PM

Yes, it calls ntpdate at startup.

What distribution... good question!

How can I find it out?
Just for argument's sake, how do I run the -g command anyway?