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
Most Stable Raspberry Pi? Better NTP with Thermal Management
21–30 of 99 posts
Re: Most Stable Raspberry Pi? Better NTP with Thermal Management
#22The related question is: Is the Pi going the Pentium 4 route?
What is this even supposed to mean? What's "the Pentium 4 route"?
Re: Most Stable Raspberry Pi? Better NTP with Thermal Management
#23Couldn'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?
Re: Most Stable Raspberry Pi? Better NTP with Thermal Management
#24The related question is: Is the Pi going the Pentium 4 route?
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.
Re: Most Stable Raspberry Pi? Better NTP with Thermal Management
#25That'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.
Re: Most Stable Raspberry Pi? Better NTP with Thermal Management
#26What'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?
Re: Most Stable Raspberry Pi? Better NTP with Thermal Management
#27What'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.
Re: Most Stable Raspberry Pi? Better NTP with Thermal Management
#28Earlier quoted context omitted.
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.
Re: Most Stable Raspberry Pi? Better NTP with Thermal Management
#29Earlier quoted context omitted.
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.
Re: Most Stable Raspberry Pi? Better NTP with Thermal Management
#30You 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:…
Very cool. What are you running on it? What's your use case?