| RE: [chrony-users] Isolated time domains |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On Fri, 6 Dec 2013, Chris Dore wrote:
On Fri, Dec 6 2013, Miroslav Lichvar wrote:
On Thu, Dec 05, 2013 at 11:39:17PM +0000, Chris Dore wrote:
As an experiment, I've got two instances of chronyd running on a server.
One instance is sourcing the external ntp servers and taking care of the
server's local clock. The second instance, is just serving up the local clock to
the clients (on a different UDP port). This is producing what I've been
describing, although I'm not a big fan of having two instances running since I
don't understand the chronyd/NTP internals well enough to know of any
gotchas that may be hiding. Also, requiring the use of a non-standard port is
less than ideal, in case an ntp client doesn't support it.
I think it should work as long as the serving instance doesn't have anything to
synchronize to. You can change the port in the client instance instead to
avoid the problem with NTP clients not supporting different NTP port.
I'll give that a shot.
How close stayed the clients in your test?
My test client running chrony has the following tracking output (poll is currently 8):
Reference ID : 10.0.0.2
Stratum : 6
Ref time (UTC) : Fri Dec 6 16:58:07 2013
System time : 0.000000421 seconds slow of NTP time
Last offset : -0.000095257 seconds
RMS offset : 0.000050311 seconds
Frequency : 83352.734 ppm slow
Residual freq : -0.158 ppm
Skew : 0.102 ppm
Root delay : 0.002094 seconds
Root dispersion : 0.000188 seconds
Update interval : 258.3 seconds
Leap status : Normal
The test server currently looks like (poll of 9):
Reference ID : 192.168.12.68
Stratum : 3
Ref time (UTC) : Fri Dec 6 17:51:38 2013
System time : 3032.924316406 seconds slow of NTP time
Last offset : 0.000256023 seconds
RMS offset : 0.000425528 seconds
Frequency : 24.272 ppm fast
Residual freq : -0.069 ppm
Skew : 0.852 ppm
Root delay : 0.103267 seconds
Root dispersion : 0.039642 seconds
Update interval : 481.7 seconds
Leap status : Normal
And just to be complete, here's the server's "local-only" instance:
Reference ID : 127.127.1.1
Stratum : 5
Ref time (UTC) : Fri Dec 6 17:10:55 2013
System time : 0.000000000 seconds fast of NTP time
Last offset : 0.000000000 seconds
RMS offset : 0.000000000 seconds
Frequency : 26.843 ppm fast
Residual freq : 0.000 ppm
Skew : 0.000 ppm
Root delay : 0.000000 seconds
Root dispersion : 0.000001 seconds
Update interval : 0.0 seconds
Leap status : Not synchronised
As Bill has also pointed out, the high slew rate (approx.. 83300 PPM in my test) is way too high for any ntpd clients to keep up. I haven't seen a config option, but is there a way to limit the rate in chrony?
If you do, it will take forever to correct any errors. With a slew rate of
80000 chrony might fix a 3 hr error in a few weeks. With a 500PPM limit it
would take 80 times as long (a few years at which point you might as well not
correct -- just let the clocks drift to their own time indepenedent of UTC,
and not care that the various servers are way way off from each other).
What ntpd will do is to clamp the slew rate to 500, very rapidly ( anumber of
poll intervals) discover the offset is way off, and do a jump. Ie, the clients
will follow with a staircase. -- ugly
I have always found it weird that the ntpd people preach about linearity,
feedback circuits, monotonicity, and then allow their system to jump, which is
highly non-linear, and non-monotonic with all the problems that can cause.
--
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.