ntpq, refclocks

Achim Gratz Stromeko at nexgo.de
Wed Jun 30 21:07:34 UTC 2021


Hal Murray via devel writes:
> I'd like to move the current kernel mode PLL to user space.  I think modern 
> CPUs are fast enough for that to make sense.  I haven't done any 
> experimentation.

That doesn't buy you what you seem to think it does.

This in-kernel PLL (at least on Linux) benefits from two things your
userland code will not be getting: it can read the raw and the corrected
time stamps of the PPS pulse in a single kernel call for getting a much
better grip on what the XO really is doing at the moment and the control
loop gets called at very regular intervals (the tick interrupt).  The
latter is why the code is no longer activated by default, because the
kernel is now tickless and the former is unfortunately tied to
configuration option for the in-kernel PLL which can't be set when the
tickless kernel is chosen, so you won't be able to use it whether you
are ion kernel mode or not.  I have some experimental code that reads
both types of timestamps from userland, but two roundtrips to the kernel
for each of them increases the jitter on their first-order difference
(which is what you'll need for the loop control) so much that you'll
need lots more averaging than you'd like.

Running usermode code from a highres timer is quite easily doable, but I
haven't tried what happens if I trigger at 100 or even 250Hz.
Triggering at 1Hz has some pretty large jitter that would either
necessitate a control strategy that doesn't assume equally spaced
samples or you'd need to reduce the jitter by successive interval
shortening (that works on the average, but can fail badly and you'd need
to filter out such samples).  I have some code that reads a PPS off an
I²C bus using that method and it still has about 1ms of jitter on it
(down from around 4…10ms without it).  The PPS timestamp for the same
PPS event has around 20…50 times lower jitter than that and most of it
is caused by the USB interface I'm using to get it registered (the
single "real" serial is used by the DCF77 receiver and no GPIO on that
computer, so it has to go in via a virtual serial port).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada



More information about the devel mailing list