Live data from Hacker News

Going in circles without a real-time clock

rachelbythebay.com

91–100 of 157 posts

Re: Going in circles without a real-time clock

#91

I've personally had so many issues with SD card corruption on raspberry pi's that I've decided it was a mistake to even allow SD card disks I only ever use USB storage on my pi's now and not had a single issue since

I heard that this is caused by not supplying enough power to the Pi, did you use the official powerbrick? I have had corruptions happen a couple of times but I have never tried with a good powersource if it actually does a difference.

Re: Going in circles without a real-time clock

#92
post #80

> I figured they must be running DNSSEC on that zone (or some part of it), and it must have a "not-before" constraint Since clients will attempt to resolve ntp.org in order to actually sync their clock, there is a good probability that some clients will be way off. Enabling dnssec on that zone was probably not without important drawbacks? I wonder if the operators thought about that potential pitfall. Seems like they…

It feels like enabling DNSSEC on any zone is inviting a bunch of fun service risks and unexpected failures.

Is my clock more likely to be accurate after NTP.org got signed? It looks like it's less likely, on average.

Re: Going in circles without a real-time clock

#93

I know I’ve brought this up before, but I can’t remember exactly where. It would be nice if DHCP could provide the current time as one of the pieces of information it provides with a lease. If you’re already trusting it for your IP address, you might as well trust it with the current UTC time: The current 64-bit timestamp would be enough to get timestamp-sensitive things working.

> If you’re already trusting it for your IP address, you might as well trust it with the current UTC time I don't follow! How does trusting DHCP with IP address automatically mean I should trust it with the current UTC time? Time requires higher degree of trust than IP. I may not care what my IP address looks like but I might care a lot about what the current UTC time is and I might want this to come from a more trus…

You don't need to trust the dhcp time. But it would be useful for bootstrapping, especially devices without rtc. This does not really apply to your average PC which probably already has good guess on current time, those can simply just ignore the dhcp provided value.

The DHCP server provided value can not be much worse than 1970-01-01T00:00:00Z default value if you don't have any other data. And if you have some other data, e.g. ext4 superblock timestamps, you can pretty trivially protect against DHCP providing time from the past (i.e. use the maximum of different sources).

Finally, you can restrict the use of the dhcp provided time to the initial bootstrapping process only; it's not necessary to use it for system-wide clock

Re: Going in circles without a real-time clock

#94

I've personally had so many issues with SD card corruption on raspberry pi's that I've decided it was a mistake to even allow SD card disks I only ever use USB storage on my pi's now and not had a single issue since

Using SD cards for an OS is a really bad idea in general. You may make it work with a read only filesystem, but if you don't sooner or later you will have issues.

Re: Going in circles without a real-time clock

#95
post #91

I've personally had so many issues with SD card corruption on raspberry pi's that I've decided it was a mistake to even allow SD card disks I only ever use USB storage on my pi's now and not had a single issue since

I heard that this is caused by not supplying enough power to the Pi, did you use the official powerbrick? I have had corruptions happen a couple of times but I have never tried with a good powersource if it actually does a difference.

SD cards are not made to run an OS from. They are quite limited in read/write cycles .

Re: Going in circles without a real-time clock

#96
It's surprising that it was left out. Ie, the workaround makes sense, but this is a peripheral that is sometimes built into MCUs themselves. For example, most (all?) STM32s include an RTC... with the caveat that if you are using them for canonical use cases, you will need external hardware in the form of a dedicated 32kHz oscillator, and possibly a battery.

For a lot of micro-controller timing uses, they aren't required; for example, hardware timers based on the primary clock source, or the Cortex-M systick, but for maintaining accurate dates and times over long periods, the RTC is the right tool. It can also output the dates and times in a convenient format as well, as long as you find named register fields convenient!

Re: Going in circles without a real-time clock

#97
post #57
post #31

Earlier quoted context omitted.

Voltage check on battery is part of regular PC maintenance. Like cleaning dust, checking all fans are spinning, capacitors are not getting bigger, checking for weird sounds in PSU, overnight memtest... You should do it every year or two...

Cannot do that if it acts as the always-on router…

Companies have regularly scheduled (weekly in some cases I know) maintenance windows affecting thousands of people. A home environment with an "always-on" router can surely find a 10 min window (say, 3 AM on a Sunday morning) where nobody cares.

Re: Going in circles without a real-time clock

#98
post #62

Earlier quoted context omitted.

I have used these in product designs before with zero failures. Where exactly did you buy your samples? We found they drift less than 28s a year in standalone mode. Also, were repeatable within +-18ms when using a NTP client. Microchip RTCs are harder to setup, but also seem to work just as well (ignoring the goofy epoch). Chip shortage caused people to do unspeakable things.... ;-)

You could buy an rtc and put up with that kind of clock drift, or.... for the same money or less you could be a GPS and have none of that drift.

(a bit more money for the GPS to be fair) not even mentioning the fact that you should have clear-ish access to the sky, the time taken for you to receive the time data, and the possibility of jamming. I could go on but the two methods have differing modes of operation and failure despite ultimately being capable of fulfilling the need for a reasonably synchronized clock

Re: Going in circles without a real-time clock

#99
post #10

Earlier quoted context omitted.

See, e.g., https://rachelbythebay.com/w/2018/04/28/meta/

Amazing. So when you read about some weird (and mostly self-inflicted) problem you've never had in your life, you are not allowed to express your surprise because by doing that you're implying you're better than other people, and that would be horrible (the implying part is what is horrible, I think? Or maybe actually being better is also wrong? Can you even be better―yeah, I guess it's possible to be better than som…

You're totally allowed to express your surprise, you're totally allowed to be a condescending jerk while doing it, you're totally allowed to call it "self-inflicted".

The author is allowed to ask you to shut up and go away if you do.

Re: Going in circles without a real-time clock

#100

Earlier quoted context omitted.

Interesting! What is the accuracy like when lacking "PPS precision"/Clayface? I'm wondering about the magnitude by which it is off (seconds, minutes, or other). PPS turned up quickly on Wikipedia, so that one is readily answered > PPS signals have an accuracy ranging from 12 picoseconds to a few microseconds per second, or 2.0 nanoseconds to a few milliseconds per day based on the resolution and accuracy of the devic…

You can see for yourself the level of accuracy in the ntpviz output. Notice the units of measurement on the graphs: * Clayface: https://www.developerdan.com/ntp/#./clayface/7-days/ * Catwoman: https://www.developerdan.com/ntp/#./catwoman/7-days/ That Wikipedia quote should mention temperature! Temperature variations have a big impact at this level of accuracy. These really cheap GPS receivers do not have temperature…

rtk gnsses really rock. I would to save up for one for next year :)
Post reply on HN