Re: [chrony-dev] PPSAPI: kernel consumer

[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-dev Archives ]


On Mon, Feb 08, 2010 at 02:57:49PM +0300, Alexander Gordeev wrote:
> > 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. 

Ok, I guess calling adjtimex and recalculating the history
every second could work.

The question is why would anyone prefer to use chrony instead of
ntpd if all the important work was done by kernel and the daemon was
used most of the time only for monitoring.

> 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 haven't done any testing, but I suspect it will be very sensitive to
noise, especially if you have removed the median filtering.

There seems to be a reason why ntpd doesn't use PPS discipline
by default, see 
http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver22.html

"As the result, performance with minpoll configured at 4 (16s) is
generally better than the kernel PPS discipline. However, fudge flag 3
can be used to enable the kernel PPS discipline if necessary."

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

It was extended not so long a go with the ADJ_OFFSET_SS_READ mode.
The extensions I'm proposing don't require modification of the struct,
just one or two more modes.

Can the MONOTONIC_RAW time be used to determine when was a frequency
change applied?

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


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/