Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Going in circles without a real-time clock

rachelbythebay.com

Post reply on HN
Print view View original

71–80 of 157 posts

Re: Going in circles without a real-time clock

#71

Post by michaelt »

M95D wrote: post #55
michaelt wrote: post #50

Earlier quoted context omitted.

Right, it's only $1. Plus the time to learn a few modprobe commands. Perhaps run a few commands echoing numbers to random sysfs files. Perhaps learn WTF a 'Device Tree Overlay' is - a concept that's completely absent on x86 systems. You see, this is an 'I2C' device, so it doesn't plug and play like USB and PCIe devices do. It is much simpler, and hence for some reason more difficult. Perhaps your device tree overlay…

If the user has issues with all of that, then RPi is not the rigth tool for them.

Ah yes the Raspberry Pi, a charitable project intended to get young kids into coding, which comes with kid-friendly projects, brightly coloured beginners' guide books, and pre-installed with Scratch, is truly only a tool for experienced professionals.

/s

Re: Going in circles without a real-time clock

#72

Post by magicalhippo »

simoncion wrote: post #65
CaliforniaKarl wrote: post #26

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.

> It would be nice if DHCP could provide the current time as one of the pieces of information it provides with a lease. [0] DHCP can provide the IP address of one or more NTP servers to consult for time queries. I use this feature so that all of the machines on my LAN (at least the ones that can be configured to ask for and/or use this information) have the same general idea of what time it is. [0] See subsection 8.3…

I do that, with a local GSP-synced Pi. Very cheap and easy to set up with IPv4 at least.

That said, if you don't trust the DHCP server because some evil actor might give you the wrong time, why should you trust the NTP server it tells you about?

Re: Going in circles without a real-time clock

#73

Post by Joker_vD »

dmvdoug wrote: post #10
wodenokoto wrote: post #5

What is she referring to by “THE ONE”?

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 someone else at something).

Re: Going in circles without a real-time clock

#74

Post by lightswitch05 »

hcfman wrote: post #64
lightswitch05 wrote: post #52

I had this happen before. I used it as an excuse to learn how to setup NTP with a GPS receiver. I made a little blog on it if anyone is interested in the results. Be sure to click the sandwich menu for some real-time data: https://www.developerdan.com/ntp/

Quick question, because I've followed a number of how tos before that don't, if you disconnected all network connectivity, would it sync to the PPS source? Second, have you tested this, I only ask because 1# I found a lot of time sync was really slow, and #2 some of them reported that they had sub-microsecond time sync but when tested they were several milliseconds out. Anyway, I solved these problems with sbts-aru,…

Good question, it absolutely syncs without any network connectivity. For better or for worse, I have it setup NOT to sync to anything else- being a stratum 1 source is enough. Now… I will admit I’m just a hobbyist with this stuff. Anyways, the way I got around it trying to sync to another source when using the PPS was to define the GPS as two separate sources. One for the PPS signal and another for the NMEA sentences:

    refclock pps ppspath /dev/gpspps0 prefer time1 0.004 minpoll 3 maxpoll 4 iburst 
    refclock nmea baud 57600 time2 0.068 minpoll 3 maxpoll 4 prefer iburst
To get around issues with sync being slow, I have NTPD configured with some extra flags to allow large time jumps at startup:

    NTPD_OPTS="-ggg -N"
I have two raspberry pies setup this way- which I don’t use for much else. My primary computers have these two servers configured as time sources- but also have external sources- so as long as network connections are available, they can determine if they are providing a sane time or are false tickers. As for accuracy, you can view the ntpviz output for each setup in the hamburger menu. For catwoman, its regularly within 4 microseconds.

Re: Going in circles without a real-time clock

#76

Post by boneitis »

lightswitch05 wrote: post #52

I had this happen before. I used it as an excuse to learn how to setup NTP with a GPS receiver. I made a little blog on it if anyone is interested in the results. Be sure to click the sandwich menu for some real-time data: https://www.developerdan.com/ntp/

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 device generating the signal.

Re: Going in circles without a real-time clock

#77

Post by riobard »

guenthert wrote: post #66
riobard wrote: post #60

Earlier quoted context omitted.

Ran `sensors` and it only shows CPU core temps. I guess my MB does not report RTC battery voltage?

One thing are the sensors, 'nother thing is the software. Have you configured the lm-sensors package (by running `sensors-detect`) yet? https://hwmon.wiki.kernel.org/lm_sensors also has a FAQ.

Yes I did run `sensors-detect` previously and just to be sure ran it again. No voltage sensors on this box unfortunately :(

Re: Going in circles without a real-time clock

#78

Post by hcfman »

lightswitch05 wrote: post #74
hcfman wrote: post #64

Earlier quoted context omitted.

Quick question, because I've followed a number of how tos before that don't, if you disconnected all network connectivity, would it sync to the PPS source? Second, have you tested this, I only ask because 1# I found a lot of time sync was really slow, and #2 some of them reported that they had sub-microsecond time sync but when tested they were several milliseconds out. Anyway, I solved these problems with sbts-aru,…

Good question, it absolutely syncs without any network connectivity. For better or for worse, I have it setup NOT to sync to anything else- being a stratum 1 source is enough. Now… I will admit I’m just a hobbyist with this stuff. Anyways, the way I got around it trying to sync to another source when using the PPS was to define the GPS as two separate sources. One for the PPS signal and another for the NMEA sentences…

Ah okay. Because I found that the default start order of gpsmon and chrony was incorrect meaning that the shared memory communications wasn't working but there were no error messages stating this. So sometimes, it would sync (slowly) and then chrony sources would say that it was having microsecond sync time but when I connected a switch (On/Off type) to the same gpio on two separate Pi's with linked earth connections and had a python program output the system time in nano seconds I found that despite telling you it was keeping time accurate to microseconds it was in fact many milliseconds out. The only thing I can conclude is that despite the setup indicating that it should use the PPS source that use the interrupt, this was in fact not happening and it was somehow getting it's time from the serial line only. Without indicating that this was happening.

When I switched the startup of gpsmon and the chrony daemon to the other way around time sync was achieved within 1/2 minute to a minute (Real fast) and the reported time on two separate Pi's with the joined up gpio's (So you can get very close to triggering a time check at the same time) was then sometimes as low as 30 ns's from each other, which is damn good considering that most of the difference would be jitter.

And none of the how-to's that I read talked about changing the start order of chronyd and gpsmon so I can only assume they all might be suffering from the same problem. It's important to note that the diagnostic commands from chrony will not indicate this and the only way you will notice if this is happening if you setup a rig like I mentioned above. I noticed because my sound localization calculations were showing errors that didn't make sense.

Re: Going in circles without a real-time clock

#80

Post by smashed »

> 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 might be doing a disservice to their core mission of allowing devices to sync their clock.

Post reply on HN