Re: [chrony-dev] PPSAPI: kernel consumer

[Alexander Gordeev <lasaine@xxxxxxxxxxxxx>]

On Mon, 8 Feb 2010 13:42:38 +0100
Miroslav Lichvar <mlichvar@xxxxxxxxxx> wrote:

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

Simply because chrony is good. And this small activity is still very
important. In my case we run distributed simulation and we need clocks
of all involved computers to be synchronised very tightly. All the
time. In this scheme there is a master which generates PPS signals and
also runs ntpd to provide it's local time to other computers. But
master's local clock slowly diverges from the astronomical time. We can
only sync it between experiments. And we want it to happen fast. ntpd
can handle this but way too slow. I'm sure, chronyd will do much better.

Also ntpd is completely unusable without the help of kernel consumer in
our setup. But chrony can be used and it doesn't need any special
support from the kernel. This is a huge advantage. And it would be
great if we don't have to configure two different time daemons (BTW
their packages are conflicting in Debian).

If you consider adding this feature I can assure you we'll test it
thoroughly.

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

I don't know what kind of noise it should prevent. But in the case when
there is little or no noise (in our case) median filtering from the
original implementation was a big trouble. It can be ok only if used
together with exponential filtering which I removed for the sake of
convergence speed. :)

Anyway, I'm going to look into chrony source to know how it can achieve
nearly the same results. And also I'm open to suggestions on how to
improve the code.

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

Well, maybe this can be true in the worst case but my tests show that
ntpd can never sync as tight as my kernel discipline.

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

Well, good luck!

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

I don't think so. But it could be used to determine frequency without
any previous calculation. If you have two MONOTONIC_RAW timestamps
for any two PPS signals you can just subtract them and divide by the
number of seconds between them and you've got the new frequency value.
MONOTONIC_RAW clock is completely untouched by the ntp subsystem in the
kernel. It's like rdtsc that was expected in the original
implementation but it doesn't suffer from CPU frequency changes and
other stuff.

-- 
  Alexander

Attachment: signature.asc
Description: PGP signature