You are not logged in.
I'm posting this topic here because NTP stands for "Network time protocol" and I couldn't find a better place to ask this.
Ever since the LTS kernel became 6.6.x, I noticed that the system needs a considerably longer time to start and "startup blame | head" reads that ntpd.service starts in nearly 30 seconds. It has never been like that before. The latest version of ntp is ancient by Arch standards (06-06-2023), so updating it is out of the question. While I was looking for ways to find out why it starts this slow, I came across this package: openntpd. So my question is this: have you ever used openntpd and if "yes", did you see any performance difference between it and ntp? I'm hoping that by replacing ntp with openntpd I'll get my system back to the normal fast boot (~5 seconds total) but before I do that, I'd like to read opinions on openntpd.
Core i7-4770, GTX 1660 Ti, 32 GB RAM, Arch 6.x LTS, Cinnamon 5.2.7, GDM
Offline
# systemd-analyze blame | grep ntp
14ms ntpd.service
...so maybe just a configuration issue?
No idea about openntpd, but
I'll get my system back to the normal fast boot (~5 seconds total)
This sounds like you don't really need to serve time but only sync your client?
Offline
Yes, I only need ntp just to properly sync time and date through the network.
Edit: I decided to take a chance and try openntpd and it seems I was right to try it. Now startup times are back to normal:
[rado@arch]: ~>$ startup-time
1.361s systemd-modules-load.service
782ms dev-sdc1.device
508ms media-4000GB.mount
433ms mullvad-early-boot-blocking.service
410ms ldconfig.service
391ms NetworkManager.service
353ms systemd-tmpfiles-setup.service
269ms lvm2-monitor.service
230ms systemd-udev-trigger.service
202ms systemd-remount-fs.service
[rado@arch]: ~>$ startup
Startup finished in 3.522s (kernel) + 3.249s (userspace) = 6.771s
graphical.target reached after 3.248s in userspace.
Last edited by rado84 (2024-01-12 12:09:12)
Core i7-4770, GTX 1660 Ti, 32 GB RAM, Arch 6.x LTS, Cinnamon 5.2.7, GDM
Offline
Now that's the 2nd time within a few days NTPD popped up as an XY-problem...
You could've just used systemd-timesyncd.service
Please mark your thread as solved by editing your first post and prepending [SOLVED] to the title.
Offline
NTP might be a parrot in the coalmine.
"nearly 30 seconds" sounds eerily like a dbus timeout and the issue might not have been the kernel change (what's unrealistic) but the somewhat coincident switch to dbus-broker.
I'd inspect the system journal itr. …
Offline
$ pacman -F startup
extra/ucblogo 6.2.4-2
usr/share/ucblogo/helpfiles/startup
$ pacman -F startup-time
$
Where do startup and startup-time commands come from ?
If they are scripts/aliases created by you, listing them might help to understand what happened.
The only
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
There's a comparison table including some performance data comparing chrony, ntp and openntp here [1] in case of any interest.
Offline