Re: [chrony-dev] Frequency transfer in NTP

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Thu, Jan 28, 2021 at 05:55:56PM -0800, Bill Unruh wrote:
> I am a bit confused. I thought that chrony delivered its best estimate of the
> time now, which might be different from the time actually shown by the system
> clock, because it was still in the process of being corrected. So, if it

Yes, that part doesn't change.

With the frequency transfer there are now three clocks involved. The
time-transfer clock and system clock are unchanged. But there is a
third clock, a frequency-transfer clock, that has the same rate as the
time-transfer clock, but it doesn't jump around, it has no epoch and
no time corrections.

> Does frequency transfer mean telling the remote clock what its estimate of the
> frequency of the local clock is? Why would that help the remote clock?

The frequency transfer still uses timestamps, just a different clock.
Imagine the client is polling exactly at 1-second interval and there
is no jitter. The receive timestamps from the two clocks in the server
responses could be:

10000.0 10001.0 10002.1 10003.1 10004.1
30000.0 30001.0 30002.0 30003.0 30004.0

The 1000x.x timestamps have an epoch. The 3000x.x don't. They just
measure an interval. Between the second and third response the server
corrected its clock by 0.1 second, but didn't change the frequency.
Without that second row, the client wouldn't know that. It would make
a wrong correction of its frequency and than later it would have to
correct it back. That's the bad response on the graphs. Normally, the
server would adjust both time and frequency, but without frequency
transfer the client cannot separate them.

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.