| Re: [chrony-users] Isolated time domains |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On Wed, 4 Dec 2013, Miroslav Lichvar wrote:
On Tue, Dec 03, 2013 at 10:43:09AM -0800, Bill Unruh wrote:
On Tue, 3 Dec 2013, Miroslav Lichvar wrote:
I think a better solution to this problem would be an approach similar
to the Google's NTP leap second smearing. The jump in time is smeared
with a cosine function over very long interval, so that the frequency
observed in the NTP time changes slowly and the clients can stay in
sync during the whole correction.
But if one, say, put in a 10PPM limit on how fast the error was corrected
(instead of chrony's 100,000 PPM limit, but more likely about 1000PPM) then it
would take about 300,000 hrs, which is years, to fix a 3 hour error. That
would be absurd. Ie, I do not think limiting chrony to slew slowly enough that
the clients can keep up (with some error) is the answer. For me,
having chrony report its best estimate of UTC rather than its local
time really is the only way to go. To slew the master slowly enough so that
the clients can keep up (presumably they would not have the slew limit
implimented) does not seem like a good option. ntpd of course gets around this
by jumping the clock (infinite slew). But that has its problems as well.
With the cosine smear, the frequency offset changes slowly (small
wander), but can reach a large absolute value.
If I calculate right, it can corrrect an offset of 10000 seconds over
1e6 seconds (11.6 days) with maximum wander of 0.05 ppm/s and maximum
frequency offset of 15915 ppm.
Althought I'm not sure if the cosine function is the best choice here
as the wander is at the maximum at the start (2nd derivative) and the
clients are possibly using their longest polling interval and will
react slowly.
I guess the above was what I was worried about. The clients take a long time
both the poll times, and the reaction time-- the time to realise that the
offsets imply that their own frequency has to change, which is many poll
intervals. Ie, even at the minimum of poll 6 (a minute) it will take many
minutes to react to a change in frequency in the client, and an attempt to
close the offset gap. And the huge change in frequency makes (15000PPM)
makes it even harder since chrony tends to resist large changes.
Ie, I would expect the clients to end up all over hell's half acre in their
offsets. But then I also expect that his 3 hr sudden offset is a far from
realistic scenario. "Lets test this package by dropping it out of a plane".
Certainly if it survives that it will survive ordinary bashing, but if it does
not, it says nothing about the value of the packaging. Similarly suddenly
displacing the server by 3 hours says little about how it will behave with
"normal" time errors.
--
William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273
Physics&Astronomy | Advanced Research | Fax: +1(604)822-5324
UBC, Vancouver,BC | Program in Cosmology | unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/
--
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.