Home / server / Questions / 259407
Accepted
joxl
Asked: 2011-04-14 12:22:34 +0800 CST

NTP fudge network source stratum

  • 772

Is it possible to configure ntpd to fudge the stratum level of a network source?

Upon first glance, I thought the fudge directive could accomplish this, however after browsing the ntp.conf(5) man pages, I found this directive only applies to Reference Clocks.

A few details:

I have a local server running ntpd as the primary time source for clients on the LAN. This server is pointed at the ntp.org pool, and usually maintains a stratum level 3.

In addition to my main server, I have a 3rd party network device whose primary job is synchronizing wall clocks wirelessly via. RF transmission. The device's specification says that it is a "RFC2030 compliant Time Server", but otherwise it's pretty much a black box. I have configured the device to use my main server as it's only time source:

black box config http://www.freeimagehosting.net/uploads/21bafb12bd.png

My problem surfaced when I configured ntpd on my personal computer to use both my main NTP server, and the wireless transmitter as time sources. When querying my local ntpd, I noticed that the "black box" (10.x.x.Z) was the favored time source:

$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
x10.x.x.X        69.164.222.108   3 u   48   64  177    0.501  370.029   1.530
*10.x.x.Z        10.x.x.Z         2 u   50   64  377    1.354  -23.681  14.179

Since server 10.x.x.Z's only time source is server 10.x.x.X (which is stratum 3), it should be stratum 4. I believe the manufacturer has hard-coded its stratum level.

Is there any way to get my machine to favor the "good" (10.x.x.X) server despite it's higher stratum level? I also tried the prefer directive in my local ntp.conf file, but to no avail, the little black box always wins :/

For what it's worth, my local machine is running Mac OS X 10.6.

$ ntpq -c rv | grep version
version="ntpd [email protected] Mon May 18 19:38:25 UTC 2009 (1)",
ntp ntpd

5 Answers

  1. Best Answer

    After some more research it seems "fudging" the stratum level of a network source is not possible. So I moved on and tried dtoubeli's answer. To my surprise, simply making my local time server a stratum level 2 (equal to the 3rd party device) did not always cause it to be the preferred time source. My local ntpd would still rule them both as "false ticks". For what reason, I'm not sure, but I'm guessing because they were the only two time sources, and their times were so far off.

    The biggest problem here is the fact that my 3rd party device doesn't seem to hold a very consistent time, in fact it fluctuates a lot. The solution to my problem was adding several other accurate time sources (pool.ntp.org) to my /etc/ntp.conf. Now my local server is always chosen as the preferred time source, often times despite having a higher stratum level than some of the servers in the pool.

    • 6

  2. You could try running your local ntpd at stratum 2. Instead of pointing it to pool.ntp.org just create a list of 5-7 stratum 1 servers and add them to configuration directly. With reference server at stratum 1 yours will be running at stratum 2. Then your prefer option may work.

    However, from my experience stratum level is not always the winning factor in primary source election. I think latency and jitter have significant influence as well. I had noticed on several occasions that lower stratum server was elected as primary source even though there were several higher stratum servers available only because it had the lowest latency. That is why I cannot guaranty that suggested approach will work.

    • 4

  3. I have a "high stratum (10)" hardware GPS time source in our local network that gives me a falsetick status (x) in ntpq, I found that using server [x.x.x.x] true (x=IP address) in ntp.conf will bypass the falsetick checking, allowing it to be a possible candidate. Looks like the stratum number does not always means higher priority.

    • 2

  4. If you don't like this server 10.x.x.Z as reference this should do the trick: 

    server 10.x.x.Z noselect

    This is useful if the server should only be used for monitoring reasons. alternatively you could also configure: 

    server 10.x.x.X prefer

    Therefore 10.x.x.Z will not be used if 10.x.x.X is available .

    • 1

  5. One reason why it is preferred is that your other time server has been unreachable recently. See the reach column?

    • 0