1

I have a ‘fun’ problem I’m trying to sort out. Bear with me!

I’ve been running a Raspberry Pi 1 B+ for a year or so as an NTPsec Stratum one timeserver - using the GPS Hat (Here’s how you can make your own: https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/)

It runs very nicely and reliably. Several days ago, I set up NTPvis on the Pi, in order to graph the performance. It generates lovely details of how the Pi is doing as a timeserver. I also started collecting temperature data, and that’s where things go a bit sideways. From the graphs, it’s become clear that the daily temperature variations are a big factor in overall accuracy of the clock. That I’m going to address separately (different case maybe, or other sort of insulation to even things out)

What also became immediately apparent however is that generating these graphs that showed me that issue, also fairly dramatically affects the temperature also!

You can have a look at the graphs here: https://ntpsec.anastrophe.com/

If you look at the temperature/frequency graphs, you’ll see the very regular big spikes in temp - those are what happen each time NTPvis runs to generate the graphs. (The glitches mid-graph are from some testing I was doing, they normally aren’t there)

Because of those spikes, it occurred to me that I have two option - get a Raspi 3 B+, put the GPS HAT in it and hope that a more powerful, quad-core box will be able to chew through those logs with much more ease than the puny Raspi 1 B+. That may then keep the temp more even.

OR, I get the Raspi 3 B+, and run it as a separate data-crunching machine - rsync the ntp log data over to it from the existing Raspi 1 B+, where it will chew through it without any temperature impact at all on the actual clock box. Or maybe NFS, still contemplating.

(You might have guessed that this was just a great excuse to buy another new Raspberry Pi to play around with, and it is!)

I guess a third option is to run the Raspi 3 B+ as the clock, and use the Raspi 1 B+ as the data cruncher - it’d be a lot slower, but there’s no real hurry to generating the graphs. I wonder if the more efficient hardware of the 3 B+ might have an even smoother temperature curve overall.

Certainly, I can test each one of these scenarios, although doing so would incur a lot more downtime, which I’d prefer to avoid.

Thoughts?

anastrophe
  • 111
  • 4
  • 1
    Have you considered adding cooling to the Pi? – Steve Robillard Jun 14 '18 at 04:39
  • Cooling would help in terms of the spikes caused by the log processing, but it won't help with the overall thermal curve due to the general ambient environment. And ambient is the overall biggest factor working against accuracy. Which is to say that this "problem" I'm solving with a new Raspi 3B+ is, as I mentioned, mostly an excuse to tinker. :) My latest idea for ambient smoothing is some closed-cell neoprene insulation, 1/16" thick, which I think will work well wrapped around just the GPS HAT. – anastrophe Jun 14 '18 at 07:58

2 Answers2

3

You have indeed hit on a variable worth controlling!

The method that Gary Miller of the NTPsec project settled on was to deliberately add CPU load, automatically adjusted to the thermal readings, to keep the temperature at a higher (but more consistent) level, using his contributed tool ntpheatusb or similar.

https://blog.ntpsec.org/2017/03/18/Watch_Your_Ts.html https://blog.ntpsec.org/2017/03/21/More_Heat.html

He even has a blog post on how to find the ideal temperature to try (automatic stepping).

https://blog.ntpsec.org/2017/03/28/Finding_zero_TC.html

Royce Williams
  • 131
  • 4
  • 1
    I had read the earlier post about heating the device up, but hadn't seen the later posts about it. It's certainly worth a try, although - burning extra watts on a low-power device like the Pi strikes me as wasteful. Although, I guess in real terms, if I decide to have a slice of toast, I've probably burned more watts than this method would use in an entire year! – anastrophe Jun 14 '18 at 15:28
  • 2
    That said, I'm trying the original 'ntpheat' program right now to see what it accomplishes. :) – anastrophe Jun 14 '18 at 15:44
0

I've seen the same problem, but took another route.

See the top answer to this question Switch out the X1 Oscillator on a RPI 2/3 which shows the massive performance improvement which can be gained from swapping the main crystal for a TCXO.

With a TCXO I can now use the NTP RPi for a variety of tasks at different CPU loading, and there is no noticeable impact on the crystal frequency.

(A similar hack is possible on other versions of the RPi, but on the RPi4 it is much more expensive due to the unusual main clock frequency.)

colintd
  • 357
  • 2
  • 10
  • Interesting idea. I'm reasonably good with a soldering iron - however, until the current and ongoing shortages of RPI's clears up, I'm not likely to go mucking about with the hardware, for fear of ...unpleasant outcomes. As it stands, my accuracy appears to be better than that shown in the graphs for the one with the TCXO. (I'm going to update the url in my question as it's been supplanted) – anastrophe Feb 21 '23 at 04:17
  • To be clear - not intending to suggest the TCXO isn't a good idea. As it stands, any time I apply Debian updates, or just the weekly backup to AWS S3, goofs the accuracy completely out of bounds. So I do think I'll do the TCXO at some point - just not now - I've been following the RPI-locator site, and have alerts set up to hit me any time any of the likely good sources have them back in stock....i think it's been a year now that i've been waiting! – anastrophe Feb 21 '23 at 04:34
  • 1
    Makes perfect sense. To be honest I was a bit cautious myself, and I've got several decades of experience of working with SMT components! In practice, the only hard bit was removing the stock crystal, and with a hot-air gun even that wasn't too bad. If you do make the change, love to know how it works out. – colintd Feb 23 '23 at 09:48