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

41–50 of 157 posts

Re: Going in circles without a real-time clock

#41

Post by hcfman »

Joel_Mckay wrote: post #22

If you are running Bind or SSL/x.509 certs, than an RTC is pretty much a requirement on the raspberry pi. Network time leaps over NTP even when working (first big leap was allowed etc.) can still bork a lot of services. Local stratum 1 GPS time (even with PPS pin) servers based on Pi's can suffer similar issues when they lose satellite lock (weather etc.) Have a great day =)

Having said that, I've never personally seen my stratum #1 Pi loose sync due to weather and I run about 4 of em here. I also use a cheap 7 euro ublox 7m. So long as you position it or an antennae with a reasonable view of the sky that shouldn't happen I reckon.

Why all the complex solutions when it's so easy and cheap now to install a stratum #1 time server, even a Pi 3 will suffice. It works on a Pi Zero, but then you only have a wifi link.

The sbts-au project make's it incredibly easy to setup. git lone and then install. One command, it's that simple.

Re: Going in circles without a real-time clock

#42

Post by apexalpha »

lifthrasiir wrote: post #23
josephg wrote: post #20

Earlier quoted context omitted.

Why does it use the time then? Why not just increment its own 96 bit number whenever you use it?

Because it is required to be monotonic per peer . WireGuard has no intrinsic states, so multiple machines with the same peer key will be seen as a single peer and that is actually a legitimate use of WireGuard. These machines would have to be synchronized to each other (but not necessarily to the external clock), and using a time is a straightforward and reasonable way to ensure this.

So could you share a single set of keys on multiple machines and Wireguard will work, as long as all machines use the same ntp server?

Re: Going in circles without a real-time clock

#43

Post by guenthert »

riobard wrote: post #14

Speaking of RTC battery, I've recently come to the realization that I have to make sure that BIOS battery is not absolutely dead in always-on PC boxes. Background: I use an x86 box as home router. I've changed the configuration in the BIOS that it should automatically boot up on power. However if the BIOS battery is dead, the config will be lost and it will revert to default settings, which is not to boot on power. B…

> But there is no way to know how much juice is left in the BIOS battery,

True, but its voltage can be used as an estimate. Most PC MB still around monitor the supply voltages, some also of the battery feeding the RTC. If you have the (Debian) package 'lm-sensors' installed, look for

    sensors[]: Vbat:           +2.91 V  (min =  +2.70 V, max =  +3.63 V)  ALARM
in /var/log/syslog.

Re: Going in circles without a real-time clock

#44

Post by pynne »

silasdavis wrote: post #30

Tangential: I have a pi 4 running openwrt and a wireguard interface that is routed over the WiFi access point. If you connect to this network it's as if you are connecting in another country. I have outbound traffic only going over wireguard. If wireguard is down then no internet (to avoid any leakage). However if pi loses power the clock resets, wireguard can't handshake with that much clock skew, NTP can't connect…

Yeah you got it. Set the listening interface to eth0 or whatever the wan interface is. Might need to get full ntpd instead of the busy box version. The Interface option here: https://www.ntp.org/documentation/4.2.8-series/miscopt/

I’m actually setting up a router with a rpi4 right now, only using Fedora IoT instead of OpenWrt. It’s a bit more assembly required lol

Re: Going in circles without a real-time clock

#46

Post by lifthrasiir »

apexalpha wrote: post #42
lifthrasiir wrote: post #23

Earlier quoted context omitted.

Because it is required to be monotonic per peer . WireGuard has no intrinsic states, so multiple machines with the same peer key will be seen as a single peer and that is actually a legitimate use of WireGuard. These machines would have to be synchronized to each other (but not necessarily to the external clock), and using a time is a straightforward and reasonable way to ensure this.

So could you share a single set of keys on multiple machines and Wireguard will work, as long as all machines use the same ntp server?

Technically yes, but I don't think (but haven't exactly confirmed) that you can initiate a new session to itself.

Re: Going in circles without a real-time clock

#47

Post by mkesper »

qiqitori wrote: post #17
riobard wrote: post #14

Speaking of RTC battery, I've recently come to the realization that I have to make sure that BIOS battery is not absolutely dead in always-on PC boxes. Background: I use an x86 box as home router. I've changed the configuration in the BIOS that it should automatically boot up on power. However if the BIOS battery is dead, the config will be lost and it will revert to default settings, which is not to boot on power. B…

Some unsolicited solutions, maybe not for you but somebody in a similar situation: maybe replace it with a supercapacitor (needs some wiring changes, otherwise it won't ever be charged, should last long enough for most power outages), or use a stack of coin cells in parallel (difficult due to physical dimensions, and they'll still go dead at some point). You can also short two wires on the ATX supply to automatically…

If using supercapacitors, use some known not for leaking else you're back to square one (do a search for capacitor recap).

Re: Going in circles without a real-time clock

#49

Post by teruakohatu »

hcfman wrote: post #41
Joel_Mckay wrote: post #22

If you are running Bind or SSL/x.509 certs, than an RTC is pretty much a requirement on the raspberry pi. Network time leaps over NTP even when working (first big leap was allowed etc.) can still bork a lot of services. Local stratum 1 GPS time (even with PPS pin) servers based on Pi's can suffer similar issues when they lose satellite lock (weather etc.) Have a great day =)

Having said that, I've never personally seen my stratum #1 Pi loose sync due to weather and I run about 4 of em here. I also use a cheap 7 euro ublox 7m. So long as you position it or an antennae with a reasonable view of the sky that shouldn't happen I reckon. Why all the complex solutions when it's so easy and cheap now to install a stratum #1 time server, even a Pi 3 will suffice. It works on a Pi Zero, but then y…

Any advice for a cheap USB GPS for a stratum #1 time server?

EDIT: Any any advice on how essential PPS is?

Re: Going in circles without a real-time clock

#50

Post by michaelt »

M95D wrote: post #8

RTC module for Raspberry is ~ $1.

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 needs to be complied? Or maybe not. Perhaps you'll edit your modules file and your kernel command line. Of course that won't involve update-grub, why would you think that?

Don't forget to periodically check on your settings, just in case an OS update or something has disabled one of those settings.

Oh and of course you won't be able to fully test this over SSH, if the network is up NTP will have set your clock whether the RTC is set up right or not. As we've learned from the article, if you run into clock problems you might not be able to connect remotely.

Then simply invent a time machine so you can do all of this in the past, before the pi SD card fails and it drops off the network.

Post reply on HN