[ntp:questions] Peering doesn't work

unruh unruh at wormhole.physics.ubc.ca
Sat Dec 18 10:31:11 UTC 2010


On 2010-12-17, Richard B. Gilbert <rgilbert88 at comcast.net> wrote:
> On 12/15/2010 7:41 AM, Mike Hauth wrote:
>> Hi everybody
>>
>> i've got a problem with my ntp configuration.
>>
>> In my infrastructure i have two servers and a couple of clients.
>> In normal case the servers should synchronize to 2 external time servers.
>
> That's your first problem.  It is written that a man with two clocks can 
> never be certain what time it is.

Except that is not his problem. Your observation may be correct, but
irrelevant.
>
> The magic numbers for a robust configuration are four, five, and seven 
> servers, protecting you against one, two, or three failing servers, 
> respectively.  Failing servers are defined as: a. not responding, or b. 
> responding with an incorrect time.
>>
>> In other cases, if the external network is not available on one or both
>> servers, the concerning server should change to local clock or rather use
>> the peering server mate via local network to synchronize to his local clock.
>>
>> But in all cases the servers should synchronize to the same time source.
>
> For a relatively modest cost ($50 -- $150), you can purchase a receiver 
> for the time broadcast by the NAVSTAR GPS satellites.  The last I heard 
> there were about twentyfive of them aloft.  There are almost always four 
> or five satellites "visible" in the sky.
>
> If properly installed and configured you can get time with an accuracy 
> of 50 nanoseconds or better.  Getting this time into a computer can 

> introduces errors that are difficult to measure.  You can generally 
> synchronize a computer to within 500 microseconds or better.
No, you cannot. The computer is incapable of initiating and going
through an interrupt on that kind of time scale. 1-2usec is possible.
And those cheap gps receivers are more like 500ns-1usec  for the time
that they deliver on their interrupt lines-- ie the rising edge of the
pulse is not accurate to better than that. 

>>
>> For this i appened the hardware clock as fallback time source with two
>> different strata (server1 has a fudged stratum of 5, server2 has a fudged
>> straum of 10).
>>
>> My expected behavior is, that server1 will be mastering server2 if both
>> servers doesn't have an network connection to the external time servers.
>> Instead they are synchronizing both to their own local clocks.
>>
>> Whats my lack of understanding?
>> How can i correct my configuration?
>>
>> I append the configuration of both servers and the output of ntpq -p.
>>
>> Hope you can help me out of this ... :-)
>>
>> By all means, have some nice christmas days!
>> Yours Mike
>>
>> ======================================================================================
>>
>> ===================
>> ### On Server 1
>> ===================
>> server1:/ # ntpq -p
>>
>>       remote           refid      st t when poll reach   delay   offset
>> jitter
>> ==============================================================================
>>   extern1         .INIT.          16 u    -   64    0    0.000    0.000
>> 0.000
>>   extern2         .INIT.          16 u    -   64    0    0.000    0.000
>> 0.000
>> *LOCAL(0)        .LOCL.           5 l   42   64  377    0.000    0.000
>> 0.001
>>   server2         LOCAL(0)        11 u   15   64  377    0.160   98.151
>> 0.057
>>
>> ------------------------------------------------------------------------------
>>
>> server1:/ # cat /etc/ntp.conf
>>
>> server extern1 maxpoll 6
>> server extern2 maxpoll 6
>> peer server2 maxpoll 6
>> server 127.127.1.0 maxpoll 6
>
> DO NOT tinker with the minpoll and maxpoll parameters.  NTPD will adjust
> the poll interval for best results in the current circumstances.

No, it will adjust them for some average circumstances. In particular
for local clocks ( like GPS) you want something like maxpoll 4 anyway.
For external sources, one of the things is to not swamp them with
requests from you and others. While I agree that he probably has no good
reason for his choice of maxpoll and should have left it alone, that is
not a blanket rule.


>
>
>> fudge 127.127.1.0 stratum 5
>>
>> driftfile /var/lib/ntp/drift/ntp.drift
>>
>> logfile   /var/log/ntp
>>
>>
>> ##############################################################################
>>
>>
>> ===================
>> ### On Server 2
>> ===================
>> server2:/ # ntpq -p
>>
>>       remote           refid      st t when poll reach   delay   offset
>> jitter
>> ==============================================================================
>>   extern1         .INIT.          16 u    -   64    0    0.000    0.000
>> 0.000
>>   extern2         .INIT.          16 u    -   64    0    0.000    0.000
>> 0.000
>> *LOCAL(0)        .LOCL.          10 l   33   64  377    0.000    0.000
>> 0.001
>>   server1         LOCAL(0)         6 u    4   64  377    0.144  -98.136
>> 0.066
>>
>> ------------------------------------------------------------------------------
>
> You need to wait at least thirty minutes after startup to get meaningful 
> output from NTPQ.  It can take as many as TEN HOURS to achieve the best 
> possible synchronization!
>
> NTPD was designed to get the most accurate time possible.  The design 

Actually no. It had a whole host of design decisions. GEtting the best
time possible was only one of them, and it is clear not a top one.
chrony for example gets about 3-20 better measured accuracy and far
faster convergence. ntpd's extremely slow behaviour has been noted
often, and Mills has valued other things higher than rapid convergence.

> assumes that you will be running NTPD twenty-four hours per day, seven 
> days a week.
>
>
><snip>




More information about the questions mailing list