|Re: [chrony-users] Isolated time domains|
[ Thread Index |
| More chrony.tuxfamily.org/chrony-users Archives
It is very confusing what you want to do.
the purpose of chrony is to discipline the clock on the computer to the best
estimate of UTC that it can. You seem to want something else. What do you
On Tue, 3 Dec 2013, Chris Dore wrote:
I just started working with Chrony since ntpd is just not meeting my needs. I've done a bit of experimentation and have Chrony working however it's not quite doing what I need and I'd like to ask if my requirements are achievable.
I'm working with systems of networked computers that are deployed into remote sites with potentially spotty internet access as well as clocks that have been manually maintained by field staff for decades. I'm looking into bringing all these remote sites in synch with our main data centre.
I assume that your main data center is on UTC.
Currently there is a master server at each site that maintains time with the other nodes via NTP. The server is currently serving up its local system clock via ntpd and the local system clock is set manually by field staff.
You mean that the master server's clock is manually set?
I would like to correct the clock on these master servers via NTP, while continuing to have to the other client nodes synchronize to the master server's local clock.
Above you said you wanted all the clocks to synced to the data center. Now you
seem to be saying something else.
I have Chrony on the master server configured with some remote servers as well as the "local" config option. The clients are using a mix of Chrony and other NTP clients and are all configured to reference just the master server.
What clients? You mean the other computers in a cluster apart from the master
in that cluster?
In my test setup I have the master server's clock set back about 3 hours and Chrony appears to be working great and is moving time towards what is reported by the external NTP servers:
Why? Is this a rediculous test? Why would you expect the master server to be 3
Reference ID : <external NTP server IP>
Stratum : 3
Ref time (UTC) : Mon Dec 2 23:54:06 2013
System time : 10695.995117188 seconds slow of NTP time
Last offset : -0.000003188 seconds
RMS offset : 0.000003775 seconds
Frequency : 25.137 ppm fast
Residual freq : 0.001 ppm
Skew : 0.091 ppm
Root delay : 0.090602 seconds
Root dispersion : 0.089578 seconds
Update interval : 7.6 seconds
Leap status : Normal
However, I need the clients of the master server to remain synchronizing against the master server's local clock and not the NTP time reported by the external servers. Looking at the chronyd instance running on one of my clients, it appears that the master server's chronyd is acting more like a proxy for the external servers:
So you do NOT want the clients to be synced to the database? Why do you want
them synced to the master rather than to UTC?
The chrony server is serving its best estimate of what UTC is.
Reference ID : <master server IP>
Stratum : 4
Ref time (UTC) : Mon Dec 2 23:54:13 2013
System time : 0.000000159 seconds slow of NTP time
Last offset : -0.000000014 seconds
RMS offset : 0.000001335 seconds
Frequency : 44.483 ppm slow
Residual freq : -0.001 ppm
Skew : 0.116 ppm
Root delay : 0.092535 seconds
Root dispersion : 0.089574 seconds
Update interval : 2.0 seconds
Leap status : Normal
This client was previously synchronized with the external NTP servers which is why it is reporting that it is in synch with NTP time. Since the master server is about 3 hours behind NTP time I need this client to say it is about 3 hours ahead of the master server.
While this example is a bit contrived, I think it illustrates that the chronyd running on the master server is telling the clients the external NTP time when I really want it to tell the clients the local system time.
Is it possible to configure chronyd to always serve it's local clock, regardless of the state of the external/remote servers?
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.