You might have even better precision if you stay away from CPU0 and also set idle=poll in your kernel command line. Lots of things (including other interrupts) often land on CPU0. It would not be my first choice for something where I wanted high timing precision.
I came here to post this. We make a lot of the same sorts of optimizations for our OS distro (debian based) -- disabling frequency scaling, core pinning, etc. Critically, CPU0 has a bunch of stuff you cannot push, and you're better off with using one of the other cores as an isolated island.
This is what the scheduler latency looks like on our isolated core:
# Total: 000300000
# Min Latencies: 00001
# Avg Latencies: 00005
# Max Latencies: 00059
# Histogram Overflows: 00000
Why not put a resistor (for heating) and a bit of foam insulation on the crystal?
This is way more direct than spacebar heating.
You could also add a transistor attached to the resistor and a GPIO and use the clock drift as a proxy for temperature. PID is probably enough but since you have a 24 hour cycle you could calculate a baseline heating schedule.
This is a technique that's been used for crystal oscillators for almost a century by now. I have some 1950s crystal ovens that are a little metal box that fits over the crystal (quite a large crystal, about the size of two or three SD cards stacked) and heats up to around 75°C. The crystals were supposed to be specially cut to have close to zero temperature coefficient around that temperature so the slight up and down drift caused by the thermostat wouldn't affect it.
I have test equipment made as recently as the early 2000s that uses a crystal oscillator in an oven as a frequency standard. It takes a good five minutes to fully stabilise.
It's an SBC-scale OXCO. I half wonder if adding a larger heatsink, or even putting thermal mass around the existing oscillator could also help, or if the heating is more localized in the PCB itself.
Always fun new things to learn when doing something "simple" like setting up an NTP server!
Flirc makes a metal Pi case where the CPU is pressed against the metal body of the case, resulting in a huge thermal mass for passive cooling. I have a bunch of them and it works very well. No fan necessary.
> or even putting thermal mass around the existing oscillator
I was thinking along these lines as well. Put a metal block on the CPU and oscillator for thermal mass (not sure if separate blocks would be better).
Ideally, with a large enough thermal capacity, the block should reach an average temperature and remain there.
Inertia is also good even if the temperature is not constant: clock drift can be measured and compensated. If the temperature rises slowly, the clock speed will increase slowly: the rate can be measured and compensated for. Jitter is the issue here, and thermal inertia should dampen it.
It may also be worth preventing convection from happening on the board. Putting the Pi in a wool sock may not be the best idea depending on its temperature, but an electrically insulating thermal conductor (or an electrical insulation layer + steel wool may do it).
Heatsinks may also be counter-productive (if they have a small thermal capacity), as their temperature depends on room temperature, which changes during the day.
I was thinking it might be nice to add some insulation around some the pi's enclosure, to reduce its cooling significantly. A little bit to tamp down any potential rapid fluctuations in the room's temperature (if someone opens a window, steps out of the bath, whatever). But more so that it could save a watt or two of power, by having the time-burner cores working much less.
You're right that this is a over-controller oscillator. The goal generally with ovens is to keep heat! (To an extent of course.)
> I half wonder if adding a larger heatsink, or even putting thermal mass around the existing oscillator could also help, or if the heating is more localized in the PCB itself.
That would likely make it worse. The trick here is that the other cores are running at essentially their maximum temperature and and will dynamically reduce their clockspeed if required to keep from going above that limit. In essence, the environment becomes actively temperature controlled. If the ambient heat goes higher, the cores clock lower, if it gets colder the cores clock higher (up to a point).
If you add too much heat dissipation, the total power used by those cores might not be enough to keep well above ambient.
1. using a second hand single frequency Ublox LEA-M8T GNSS receiver is not a good idea in 2025 when a dual frequency GNSS receiver chip can be purchased online for as little as $20-30. buy one of those ublox ZED-F9P receivers with the 2018/2019 firmware, they get you the exact same timing performance as ZED-F9T with QEerr support. PPS jitter is going to drop from 20ns to less than 2ns after qErr compensation.
2. you can replace that highly unstable crystal oscillator with a $10 used OCXO + $20 PLL board and save that PID temperature controller to be used as the secondary oven for that OCXO. people have been doing that for Raspberry Pi for ages.
3. or you can configure your GNSS receiver to output a 10Hz signal from the PPSOUT pin so chrony can get 10 updates per second, GNSS receiver's internal TCXO is going to be more stable than raspberry Pi's crystal oscillator.
4. for more fun - just keep measuring the frequency drift vs. temperature change. a sample set of 24-48 hours of such measurements should be enough to figure out the tempco of that unstable crystal oscillator so you can get chrony to do the drift compensation. from memory, chrony supports such a temperature compensation lookup table to be specified.
Couldn't you model the effect of temperature on clock drift and try to factor that in dynamically (e.g. using a temperature sensor) instead of burning CPU unnecessarily?
Sure, that's what the chrony closed loop is already doing (the estimated residual frequency is pretty linear with temperature), but no matter how robust your closed loop is, it's strictly better to not have disturbances in the first place.
That's what the chrony tempcomp directive is for. But you would have to figure out the coefficients, it's not automatic.
An advantage of constantly loading at least one core of the CPU might be preventing the deeper power states from kicking in, which should make the RX timestamping latency more stable and improve stability of synchronization of NTP clients.
Amazing project, great write-up. Would love to see a temperature graph as well! I'm wondering how good the PID controller here is working.
For future improvements, a cheap but effective win might be to put a temperature sensor on the oscillator (or two or three in various places). And use that to drive the PID loop.
Even if just experimental & not long term, it would be nice to have data on how strong the correlation is between the cpu & oscillator temperatures. To see their difference and how much that changes over time. Another graph! CPU vs txco (vs ambient?) temperatures over time.
You can do that as well, but (in theory) the correction will be smaller than it otherwise would need to be if the temperature is regulated within a narrower range.
That's a neat software solution. My first inclination would be to grab a soldering iron and replace the crystal with either a TCXO or a socket to provide an external clock disciplined to the 1PPS.
In 2025, there are extremely efficient CPUs from Intel and Apple. Under 5W idle!
The old Intel CPUs were grotesquely inefficient. Every single generation of Raspberry Pi has been well under 5W idle. And just so it's clear, the author is using an old Raspberry Pi 3.
From TFA:
> The RPi 3B’s 19.2 MHz oscillator is physically located near the CPU on the Raspberry Pi board, so by actively controlling CPU temperature, we’re indirectly controlling the oscillator’s temperature.
Also note that the R.Pi can even be further optimised by switching off HDMI.
Intel tried to scale frequency up with the Pentium 4 in the name of performance, and it ended up extremely hot and power hungry. Just like some high end CPUs now, but then it applied to every model from Intel.
I suppose you don't remember when a Raspberry Pi could run fine even without a heatsink, let alone active cooling. That's more recent than the Pentium 4.
It's already there really. It's heat output on the 4 and more so the 5 benefits from active cooling. The good news is the pi is practically pointless as a product for most people these days, and vastly better options are available cheaper, so unless you genuinely need the gpio theres little reason to buy one - very much their own fault for focusing on commercial applications but the Pi 5 as a product is practically pointless for a consumer use at this point. An old Pi 2 or 3 which dont need any cooling are very useful still for a range of applications but the newer ones are in a bit of a weird niche where they're overpriced compared to most options.
What's the point in reading posts like this when the solution "they" came up with is basically, "tell Claude to make a script which does whatever"? I read blog posts to read thoughts from people, not computers
Are you similarly frustrated that he didn't sit there 24/7, heating the oscillator with a small lighter when needed, but automated it instead? Why would this be more interesting for you if he'd written the script himself?
It doesn't become claude's insight just because the user instructed it to write some trivial bash script.
Then again these are all well known optimizations (core-pinning, frequency-locking, thermal stabilization for oscillators). The interesting part is the actual measurement results over multiple days. That's something you can't get from a single prompt.
You might have even better precision if you stay away from CPU0 and also set idle=poll in your kernel command line. Lots of things (including other interrupts) often land on CPU0. It would not be my first choice for something where I wanted high timing precision.
I came here to post this. We make a lot of the same sorts of optimizations for our OS distro (debian based) -- disabling frequency scaling, core pinning, etc. Critically, CPU0 has a bunch of stuff you cannot push, and you're better off with using one of the other cores as an isolated island.
This is what the scheduler latency looks like on our isolated core:
# Total: 000300000 # Min Latencies: 00001 # Avg Latencies: 00005 # Max Latencies: 00059 # Histogram Overflows: 00000
(those are uS!)
Very cool. What are you running on it? What's your use case?
Why not put a resistor (for heating) and a bit of foam insulation on the crystal?
This is way more direct than spacebar heating.
You could also add a transistor attached to the resistor and a GPIO and use the clock drift as a proxy for temperature. PID is probably enough but since you have a 24 hour cycle you could calculate a baseline heating schedule.
This is a technique that's been used for crystal oscillators for almost a century by now. I have some 1950s crystal ovens that are a little metal box that fits over the crystal (quite a large crystal, about the size of two or three SD cards stacked) and heats up to around 75°C. The crystals were supposed to be specially cut to have close to zero temperature coefficient around that temperature so the slight up and down drift caused by the thermostat wouldn't affect it.
I have test equipment made as recently as the early 2000s that uses a crystal oscillator in an oven as a frequency standard. It takes a good five minutes to fully stabilise.
It's an SBC-scale OXCO. I half wonder if adding a larger heatsink, or even putting thermal mass around the existing oscillator could also help, or if the heating is more localized in the PCB itself.
Always fun new things to learn when doing something "simple" like setting up an NTP server!
Flirc makes a metal Pi case where the CPU is pressed against the metal body of the case, resulting in a huge thermal mass for passive cooling. I have a bunch of them and it works very well. No fan necessary.
> or even putting thermal mass around the existing oscillator
I was thinking along these lines as well. Put a metal block on the CPU and oscillator for thermal mass (not sure if separate blocks would be better). Ideally, with a large enough thermal capacity, the block should reach an average temperature and remain there.
Inertia is also good even if the temperature is not constant: clock drift can be measured and compensated. If the temperature rises slowly, the clock speed will increase slowly: the rate can be measured and compensated for. Jitter is the issue here, and thermal inertia should dampen it.
It may also be worth preventing convection from happening on the board. Putting the Pi in a wool sock may not be the best idea depending on its temperature, but an electrically insulating thermal conductor (or an electrical insulation layer + steel wool may do it).
Heatsinks may also be counter-productive (if they have a small thermal capacity), as their temperature depends on room temperature, which changes during the day.
I was thinking it might be nice to add some insulation around some the pi's enclosure, to reduce its cooling significantly. A little bit to tamp down any potential rapid fluctuations in the room's temperature (if someone opens a window, steps out of the bath, whatever). But more so that it could save a watt or two of power, by having the time-burner cores working much less.
You're right that this is a over-controller oscillator. The goal generally with ovens is to keep heat! (To an extent of course.)
> I half wonder if adding a larger heatsink, or even putting thermal mass around the existing oscillator could also help, or if the heating is more localized in the PCB itself.
That would likely make it worse. The trick here is that the other cores are running at essentially their maximum temperature and and will dynamically reduce their clockspeed if required to keep from going above that limit. In essence, the environment becomes actively temperature controlled. If the ambient heat goes higher, the cores clock lower, if it gets colder the cores clock higher (up to a point).
If you add too much heat dissipation, the total power used by those cores might not be enough to keep well above ambient.
Extreme power dissipation would keep temperature stable so that this whole setup might not be needed, though.
Author should experiment with liquid nitrogen ;) [1]
[11] https://www.xda-developers.com/liquid-nitrogen-cooling-raspb...
The timing crystals don't work better when colder but worse. That's why they are heated in high end time appliances, not cooled.
Isn't the issue here temperature stability? (Also, humour)
Right, and they are heated because a hot wire is much simpler than a fridge.
some ideas -
1. using a second hand single frequency Ublox LEA-M8T GNSS receiver is not a good idea in 2025 when a dual frequency GNSS receiver chip can be purchased online for as little as $20-30. buy one of those ublox ZED-F9P receivers with the 2018/2019 firmware, they get you the exact same timing performance as ZED-F9T with QEerr support. PPS jitter is going to drop from 20ns to less than 2ns after qErr compensation.
2. you can replace that highly unstable crystal oscillator with a $10 used OCXO + $20 PLL board and save that PID temperature controller to be used as the secondary oven for that OCXO. people have been doing that for Raspberry Pi for ages.
3. or you can configure your GNSS receiver to output a 10Hz signal from the PPSOUT pin so chrony can get 10 updates per second, GNSS receiver's internal TCXO is going to be more stable than raspberry Pi's crystal oscillator.
4. for more fun - just keep measuring the frequency drift vs. temperature change. a sample set of 24-48 hours of such measurements should be enough to figure out the tempco of that unstable crystal oscillator so you can get chrony to do the drift compensation. from memory, chrony supports such a temperature compensation lookup table to be specified.
good luck and have fun
Couldn't you model the effect of temperature on clock drift and try to factor that in dynamically (e.g. using a temperature sensor) instead of burning CPU unnecessarily?
Sure, that's what the chrony closed loop is already doing (the estimated residual frequency is pretty linear with temperature), but no matter how robust your closed loop is, it's strictly better to not have disturbances in the first place.
That's what the chrony tempcomp directive is for. But you would have to figure out the coefficients, it's not automatic.
An advantage of constantly loading at least one core of the CPU might be preventing the deeper power states from kicking in, which should make the RX timestamping latency more stable and improve stability of synchronization of NTP clients.
It's the good old OCXO - Oven Controlled Crystal Oscillator. But the heating element is the CPU. Fucking hilarious.
There was a paper on this in 2022. Not sure if it's used in production or not.
https://www.usenix.org/conference/nsdi22/presentation/najafi
Cool paper. Their modeling of the temperature response curve seems a more elegant (albeit non-trivial) solution than burning CPU.
I wonder about using an RPI Pico for this instead, using the Pico's synchronous PIO gizmo to intercept the PPS pulses.
A microsecond is still quite a lot if GPS is involved, that's about 1000 light-feet!
How much is it in eagle wingspans ?
Bald, golden, or other?
Or do we have a defined standard eagle these days?
or 300 light-meters
Wouldn't a temperature compensating algorithm be just as effective?
I love this. Chasing perfection for perfection alone.
Amazing project, great write-up. Would love to see a temperature graph as well! I'm wondering how good the PID controller here is working.
For future improvements, a cheap but effective win might be to put a temperature sensor on the oscillator (or two or three in various places). And use that to drive the PID loop.
Even if just experimental & not long term, it would be nice to have data on how strong the correlation is between the cpu & oscillator temperatures. To see their difference and how much that changes over time. Another graph! CPU vs txco (vs ambient?) temperatures over time.
> put a temperature sensor on the oscillator
At that point, couldn't we just use the temperature value to compensate for the drift?
You can do that as well, but (in theory) the correction will be smaller than it otherwise would need to be if the temperature is regulated within a narrower range.
That's a neat software solution. My first inclination would be to grab a soldering iron and replace the crystal with either a TCXO or a socket to provide an external clock disciplined to the 1PPS.
The related question is:
Is the Pi going the Pentium 4 route?
In 2025, there are extremely efficient CPUs from Intel and Apple. Under 5W idle!
The old Intel CPUs were grotesquely inefficient. Every single generation of Raspberry Pi has been well under 5W idle. And just so it's clear, the author is using an old Raspberry Pi 3.
From TFA:
> The RPi 3B’s 19.2 MHz oscillator is physically located near the CPU on the Raspberry Pi board, so by actively controlling CPU temperature, we’re indirectly controlling the oscillator’s temperature.
Also note that the R.Pi can even be further optimised by switching off HDMI.
https://www.pidramble.com/wiki/benchmarks/power-consumption
https://www.jeffgeerling.com/blogs/jeff-geerling/raspberry-p...
What is this even supposed to mean? What's "the Pentium 4 route"?
I'm an old fart :)
Intel tried to scale frequency up with the Pentium 4 in the name of performance, and it ended up extremely hot and power hungry. Just like some high end CPUs now, but then it applied to every model from Intel.
I suppose you don't remember when a Raspberry Pi could run fine even without a heatsink, let alone active cooling. That's more recent than the Pentium 4.
It's already there really. It's heat output on the 4 and more so the 5 benefits from active cooling. The good news is the pi is practically pointless as a product for most people these days, and vastly better options are available cheaper, so unless you genuinely need the gpio theres little reason to buy one - very much their own fault for focusing on commercial applications but the Pi 5 as a product is practically pointless for a consumer use at this point. An old Pi 2 or 3 which dont need any cooling are very useful still for a range of applications but the newer ones are in a bit of a weird niche where they're overpriced compared to most options.
What's the point in reading posts like this when the solution "they" came up with is basically, "tell Claude to make a script which does whatever"? I read blog posts to read thoughts from people, not computers
Are you similarly frustrated that he didn't sit there 24/7, heating the oscillator with a small lighter when needed, but automated it instead? Why would this be more interesting for you if he'd written the script himself?
> Are you similarly frustrated that he didn't sit there 24/7, heating the oscillator with a small lighter when needed, but automated it instead?
No
> Why would this be more interesting for you if he'd written the script himself?
Was I unclear? I read blog posts to read thoughts from humans, not from computers.
Well, I guess your era of reading is over, sadly.
It doesn't become claude's insight just because the user instructed it to write some trivial bash script.
Then again these are all well known optimizations (core-pinning, frequency-locking, thermal stabilization for oscillators). The interesting part is the actual measurement results over multiple days. That's something you can't get from a single prompt.
But here's the key insight: what's the point in reading posts where the post itself is "tell Claude to write a post about…"