#chrony — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #chrony, aggregated by home.social.
-
Stratum 1 NTP-сервер на Raspberry Pi в 2026 году: DCF77 + GPS/PPS, chrony, libgpiod v2
Stratum 1 NTP-сервер на Raspberry Pi в 2025 году: DCF77 + GPS/PPS, chrony, libgpiod v2, когда все туториалы по «точному времени на Raspberry Pi» сломаны на современных системах. Разбираю почему — и показываю как сделать правильно.
-
Secure time synchronization with NTS
To set the correct time on computers, usually NTP (Network Time Protocol) is used. However NTP is an insecure time synchronization protocol and allows a man-in-the-middle to shift time on an NTP client. To tackle these issues, NTS (Network Time Security) was created which aims to solve these problems. In this article I show how you can configure ntpd-rs and Chrony to use NTS servers. systemd's timesyncd does not support yet NTS, but it's currently in development so hopefully this will be […]https://blog.frehi.be/2026/03/29/secure-time-synchronization-with-nts/
-
Needed an #NTP server on a Raspberry Pi. To keep it light, I chose #OpenNTPD.
Not a great idea.
If your clock is off by more than 180 seconds, it won't adjust it; logs say
adjtime failed: Invalid argument
Now, according to the man page, it will jump to adjust larger offsets on startup, but apparently #Debian has patched this to require adding `-s` to /etc/default/openntpd.
They also don't support `constraint from` config stanzas used to get a trusted date via HTTPS.
Trying #chrony now.
-
I configured #chrony shipped with #ProxmoxVE to operate as a server and set up #DNS records on my router to point ntp[1-4].aliyun.com to the local IP of the #Proxmox node with chrony.
According to the internet, ntp[1-4].aliyun.com are 4 of 8 NTP servers used by #PhilipsHue bridge.
Then I blocked internet access for the bridge.
Now we wait and see if it works.
#chrony #proxmoxve #dns #proxmox #philipshue #homelad #selfhost #selfhosted #selfhosting #offline
-
NTP in practice. Mostly it works. Time to time it's like 8 hours off. Internet connection is working.
I already debugged unreliable NTP once and replaced the unreliable "ntp" NTP daemon with much more reliable "chrony" NTP daemon. But still unreliable.
"Old people don't like computers" - because computers are unreliable! Why would I use something that's unreliable? A tuning fork ground out of quartz, invented by Seiko, connected to a battery, semiconductor amplifier, 15-bit counter, few logic gates, stepper motor, cogwheels, hands and a clock face is much more reliable!
#ntp #unreliable #linuxfail #linux #chrony #ntpd #reliability
-
Made progress on packaging #ntpd_rs by @trifectatech for @gentoo :
✅ proper hermetic Rust build
✅ cooked up OpenRC init scripts
✅ runs unprivileged as ntp:ntp
✅ operational #prometheus metrics exporter
✅ man pagesStill a few rough edges but getting there!
#chrony is currently still the better choice but alternatives are always good. -
GPS-gestützter Zeitserver mit Raspberry Pi: So baust Du Deine eigene Grandmaster Clock
Mit einem Raspberry Pi und einem GPS-Empfänger lässt sich ein präziser Stratum-1 Zeitserver aufbauen – inklusive PPS-Signal und PTP-Unterstützung. So entsteht eine kostengünstige Alternative zu teuren Grandmaster Clocks, die exakte Zeit im ganzen Netzwerk be
#chrony #Clock #gps #grandmaster #nmea #ntp #ntpd #pi #pps #rasbian #raspberry #zeitserver
-
Montando um servidor de hora com Chrony e gpsd https://cadu.cc/blog/montando-um-servidor-de-hora-com-chrony-e-gpsd.html
-
My overnight tests finished!
In my environment, I get the best #NTP accuracy with #Chrony when using `minpoll -2 maxpoll -2` and not applying any filtering. That is, have the client poll the NTP server 4 times per second. Anything between `minpoll -4` (16x/second) and `minpoll 0` (1x/second) should have similar offsets, but the jitter increases with fewer than 4 polls per second.
https://scottstuff.net/posts/2025/06/03/measuring-ntp-accuracy-with-an-oscilloscope-2/
Chrony has a `filter` option that applies a median filter to measurements; the manual claims that it's useful for high-update rate local servers. I don't see any consistent advantage to `filter` in my testing and larger filter values (8 or 16) consistently make everything worse.
When polling 4x/second on a carefully constructed test network, NTP on the client machine is less than 2 ns away from #PTP with 20 ns of jitter. I know that PTP on the client is 4 ns away from PTP on the server (w/ 2 ns of jitter), as measured via oscilloscope.
So, you could argue that this counts as single-digit nanosecond NTP error, although with 20 ns of jitter that's probably a bit optimistic. In any case, that's *well* into the range where cable lengths are a major factor in accuracy. It's a somewhat rigged test environment, but it's still much better than I'd have expected from NTP.
-
Ubuntu 25.10 Questing Quokka will use chrony to replace systemd-timesyncd to improve security.
#Ubuntu #Linux #UbuntuLinux #Computers #Laptops #TechNews #TechUpdates #chrony #QuestingQuokka
-
Okay, this is weird. My one ConnectX-4 system *really* dislikes running #linuxptp.
I'm currently using #Chrony for NTP sync; in *some* cases linuxptp/ptp4l gives better results., but *not* with ConnectX-4 NICs. I'm judging result quality by tracking the RMS offset from `chrony tracking`, as collected by the Prometheus Chrony collector.
As a steady state, my test system sees 25-40ns of RMS offset time. Nice and steady. Chrony is talking to 3 local NTP servers plus some pool servers, with `hwtimestamp *` set but no `refclock` config.
Just starting up `ptp4l` in the background (where it syncs PTP time from the network onto the NIC's PTP Hardware Clock, but *doesn't* touch the system clock) causes chrony's tracking error to jump from ~40ns to ~900ns. Stopping `ptp4l` makes the errors go away immediately.
In this state, there shouldn't be *any* interaction between Chrony and ptp4l at all, but I see a 45x increase in timing error.
Disabling `hwtimestamp *` doesn't help at all. I could see some weird dependency on the PHC when HW timestamps are used, but disabling them doesn't help at all.
This is on Ubuntu 24.04, with Linux 6.8.0-59 and linuxptp 4.0-1ubuntu1. It's using a MCX456A-ECAx NIC (psid MT_2190110032). I originally observed this with FW 12.27.4000; upgrading to the latest FW (12.28.2302) and rebooting showed no change.
I don't see similar problems w/ ConnectX-5.
*In addition to chrony being unhappy*, ptp4l isn't really syncing correctly, either. It's logging RMS errors that look mostly random, between 20 and 50000ns of error, with no real indication of setting down into sync.
For comparison, my pair of Intel X710 systems run with <15ns of RMS error via the same linuxptp build and same switch infra.
-
On the other hand, using #PTP to sync time to my web servers is a big win. They're behind a software router and using PTP with Intel NICs drops the sync error from ~10 us to ~5 ns, according to #Chrony. This is mostly because time is bypassing the firewall entirely and being distributed directly by the switch, so there's far less jitter.
I'm not quite sure what a 5 ns time error means when devices are more than 2.5 feet apart, but lets ignore that for now.
-
@erincandescent If a thing's worth doing, then it's worth over-doing. I'm now running the #Prometheus #Chrony exporter on 5 systems now, and using the error metric from its GH page, it looks like I'm running 50-100 usec of #NTP error now, which should be more than good enough.
-
Huh. Now that I have #otel traces on a bunch of things at home, it's pretty clear that my clocks aren't in sync on every system. They're maybe 1ms off, but it's enough that supposedly-nested trace spans aren't quite nested right.
Which is annoying since I have two local GPS #NTP receivers.
The two "bad" machines were using #systemd-timesyncd to talk to Ubuntu's pool clocks instead of the local clocks. The "good" machines are using #chrony and claim that they're ~2 us off of GPS time.
Now I'm curious -- is this a problem with network latency and Ubuntu's pool, or is that just as good as timesyncd gets?
-
@mark @M0CUV Perhaps some info here on clocks via GPS, very tantalising rabbit hole....
https://openwrt.org/docs/guide-user/services/ntp/gps
https://github.com/domschl/RaspberryNtpServer
https://github.com/tiagofreire-pt/rpi_uputronics_stratum1_chrony
#gps #stratum1 #ntp #chrony #ntpd -
Habe mal wieder ein neues Nerd-Projekt: Ein eigener Stratum 1 NTP-Zeitserver. Warum? Weil es geht. Die Daten kommen per GPS und haben dadurch eine Genauigkeit im Bereich von Nano-Sekunden. Der Testaufbau läuft, jetzt muss ich nur noch ein passendes Gehäuse drucken und eventuell die Antenne noch draußen positionieren.
-
Anyone upgrading #TrueNAS from their 24.10 release candidate to the full release should be aware that it clobbers a lot of purportedly local override configuration files not accessible from the GUI. Basically, anything not configured by their "middleware" (i.e. their custom #WebUI) is likely to go bye-bye. The #ZFS file systems and pools should be fine, though; just have a backup in case you've had to tweak #AppArmor, #Chrony, /etc/default/*, or anything else that isn't available via the web UI.
-
NTP – Zeitserver
Ein neuer adminForge Service kann ab sofort genutzt werden.Eine geographische Nähe zu einem Zeitserver ist wichtig um die höchstmögliche Genauigkeit der Zeitsynchronisation zu bekommen. Du kannst jeden unserer Server in deiner NTP-Konfiguration verwenden. Alle Server nehmen auch an dem NTP-Pool-Projekt teil.
Server
IP-Adressen
Stratumntp1.adminforg
https://adminforge.de/tools/ntp-zeitserver/
#Tools #adminforge #chrony #ntp #Timeserver #Zeitserver -
```
root@zwergenland:~# chronyd -Q -t 3 'server ptbtime1.ptb.de iburst maxsamples 1'
2024-07-07T12:24:35Z chronyd version 4.4 starting (+CMDMON +NTP +REFCLOCK -RTC +PRIVDROP -SCFILTER -SIGND +ASYNCDNS +NTS -SECHASH +IPV6 -DEBUG)
2024-07-07T12:24:35Z Disabled control of system clock
2024-07-07T12:24:36Z System clock wrong by 887290.072863 seconds (ignored)
2024-07-07T12:24:36Z chronyd exiting
```
