| Re: [chrony-dev] PPSAPI: kernel consumer |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
On Mon, 8 Feb 2010, Alexander Gordeev wrote:
On Mon, 8 Feb 2010 10:14:52 +0100
Miroslav Lichvar <mlichvar@xxxxxxxxxx> wrote:
On Sat, Feb 06, 2010 at 04:32:13AM +0300, Alexander Gordeev wrote:
Do you plan to add a way to bind kernel consumer in chrony's new PPS
driver? This is an optional feature of PPSAPI as you surely know.
I'm not sure chrony will be able to use it. If I understand it
correctly, it would need to give up control over frequency and phase
adjustments which is necessary for keeping source stats accurate.
Right, you have to give up the control. But I don't understand why it's
a problem... You can monitor frequency changes using adjtimex and
phase changes using PPS signal itself. After all in this mode the
user-space time daemon is used primarily to unbind PPS kernel consumer
when the local time has changed in a leap and is more than a second
from the standard. Then it adjusts the time and binds the kernel
consumer back. I like chrony very much because it can do its job really
good. But the kernel implementation is so very simple and
straightforward and works good as well. And this is a part of PPSAPI.
I mean that it would be great to have choice.
I am not sure at all what is really being discussed here, but the chrony
philosophy of disciplining the time is really very different from the ntp, or
the kernel philosophy. chrony relies on memory-- it remembers what the offsets
were and uses those to get a much better estimate of how the system clock is
behavingi (it remembers up to 64 past time measurements, and updates them when
the frequency or offset estimates change) That really does not belong in the
kernel. . Sticking that into the kernel would really result in kernel bloat.
If you want to use an ntp like mechanism with its one single memory cell (the
clock rate), then use ntp. You have that choice.
I've tested chrony's PPS driver and I'm really shocked with its
synchronization quality. It is a HUGE improvement over ntpd. It was
hard to believe that it can sync clock with a precision of 1-2us but
it is true. However, my new kernel consumer seems to be able to
keep the same precision, but it can sync faster (in few seconds).
I think chrony could do that too if the kernel interface allowed a
tight loop.
This could be an extension to adjtimex which would allow us to know
either remaining singleshot adjustment (ideally in nanoseconds) or
when exactly did the last change in frequency happen.
I doubt that adjtimex will ever be extended. In the kernel I use
MONOTONIC_RAW clock to calculate frequency adjustments and REALTIME
clock for the phase. Seems to me this is the most straightforward way.
But AFAIK MONOTONIC_RAW is Linux-specific.
---
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.