Re: [chrony-users] Isolated time domains

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

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.

-- 
Miroslav Lichvar

-- 
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.