[time-nuts] Re: "software TCXO" on commodity computers

[ASSI]

On Dienstag, 5. April 2022 06:36:01 CEST Bernd Neubig wrote:
> Strange enough that the frequency error vs. temperature has a shape just
> opposite to that of a tuning fork crystal, where the vertex ("turning
> point")of the parabola is the maximum frequency.

That's an easy mistake to make when you look at the correction you make rather 
than the actual error, especially when you throw in NTP loop readings -- I can 
never remember which way it reports the frequency deviation.  The crystal 
driving the clock is not a tuning fork anyway, but these days typically some 
SMD thing between 20…100MHz that drives a clock generator with multiple 
outputs (one of which is the "system clock" that everything else around and 
inside the CPU will be related to via rational multiplicators.

On Montag, 4. April 2022 20:59:01 CEST Jeremy Elson wrote:
> This just won the Best Paper award at NSDI 2022:
> 
> https://www.usenix.org/system/files/nsdi22-paper-najafi_1.pdf
> 
> It's a clever idea: they observe that most commodity computer motherboards
> have temperature sensors onboard, and found a correlation between clock
> frequency and the output of that temperature sensor. Using that model they
> were able to build a "pure software TCXO" that maintains frequency an order
> of magnitude better than the typical performance of a crystal without the
> corrections.

They managed to completely miss all the RADclock papers

https://www.synclab.org/

…which is mildly surprising.  The Allan deviation measurements done by SyncLab 
folks still represent one of the most believable source for this sort of 
information and it's been out there for years.

Also, chrony has had a temperature based feed forward correction built in from 
I don't know when -- it's been in there seemingly forever, but at least since 
2010.

https://blog.dan.drown.org/beaglebone-black-ntpgps-server-temperature-compensation/

(Note: you'll see the same inverted f(T) curve in the plot there.)

The better way on modern Linux is to use the RAW MONOTONIC timestamps as that 
allows to monitor the actual clock before the corrections applied by the 
kernel (through NTP).  It's vastly easier to converge to a good estimate of 
the frequency deviation (rather than the time deviation) this way.  
Unfortunately it's not possible to get both the raw and corrected time stamps 
in a single call via the PPS device or otherwise (at least not with an 
unmodified kernel or a very unusual kernel configuration -- NTP kernel PLL, 
which is incompatible with power saving features of recent kernels).  Getting 
these timestamps from userspace via separate kernel roundtrips adds extra 
noise on top of what you inevitably already get when feeding in a signal via 
an interrupt.  Even so, using a time interval close to the (assumed) minimum 
of the Allen deviation curve gives pretty good estimates even without extra 
filtering.  See the two attached plots for what that ends up looking like.  
One is from a rasPi that's self-ovenized so that's a roughly 40ppb scale, the 
other from an Intel box that is free-running, so the scale is a few ppm there.  
Timestamp accuracy is about 40 times better on the rasPi because it uses a 
GPIO, while the Intel box has to get the PPS in via DCD of a serial port.

A more sticky problem is that no temperature sensor reports the crystal 
temperature, something I've had to compensate for in my self-ovenized rasPi 
and TinkerBoards to actually keep the crystal at constant temperature (around 
the turning point of the f(T) curve for better stability).  This is related to 
different sources of heat in the system and how it dissipates out, something 
that is undoubtedly more complicated in a server system and would require to 
actually use all the temperature sensors (and not just the one they've 
"learned" is the best).

The problem with the numerical validity of fitting cubics across two points 
could have been easily avoided by using a quadratic function.  I've yet to 
find a crystal where a parabola does not fit well enough considering all the 
other uncertainties in that sort of determination.


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

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NTP_vs_MonotonicRaw2.png
Type: image/png
Size: 73045 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20220405/88be06bd/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NTP_TimerMonitoring_rPi5.png
Type: image/png
Size: 128797 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20220405/88be06bd/attachment-0001.png>