Dennis Ferguson writes:

>The reason I think you're better off with the device is that the kernel
>PLL thing, while it looks seductively generic, actually has more dependence
>on it being xntpd which supplies the adjustments than meets the eye (this
>is part of the reason I'm not fond of that code being in the kernel).If
>you do the device you retain the option of either using xntpd, which will
>give you the best result, or writing a minimal thing to just compute offsets
>and shove the result back into the kernel, which will give you results
>which are in no way inferior to what you'd end up with with an all-kernel
>implementation.

I read this as an attempt to use an ISDN timesource as additional
source of phase (or, perhaps better, frequency) info for someone who's
*already* running xntpd in some intermittenly-connected mode, or who
has a dodgy system clock.  Running in FLL mode and handing the
adjustments to the inkernel code seems cleanest in that case.

Otherwise, computing the offsets from the ISDN timestamp is the easy
bit.  You then want to fold the offsets into the system time smoothly.
Sounds to me like one would start off with adjtime(2), start worrying
about a previous adjustment not completing before the next is added.
One could quite easily end up slowly reinventing xntpd, only perhaps
not as well :).