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
Going in circles without a real-time clock
91–100 of 157 posts
Re: Going in circles without a real-time clock
#92> 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…
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
#93I 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…
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
#94I'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
Re: Going in circles without a real-time clock
#95I'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
#96For 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
#97Earlier 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…
Re: Going in circles without a real-time clock
#98Earlier 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.
Re: Going in circles without a real-time clock
#99Earlier 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…
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
#100Earlier 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…