I just noticed https://www.ntpsec.org/, and their goals look OK to me. Is anybody using their software on pool servers already?
Hadn’t heard of them previously but the idea of reducing attack surfaces and removing cruft is definitely a good one. Next time I’m adding or changing servers I’ll consider the option as an alternative.
I am, on 3 servers in the pool. One of them is Stratum 1, the other two are Stratum 2.
Works well.
Yes I use NTPSec, on both my Stratum-0 and Stratum-1. Functionally compatible to the base NTP daemon, and I like the included utilities for monitoring server performance and incoming queries.
I’m now using it on a stratum 1 and stratum 2 server. Looking good!
Has anyone given it a try under load, is it multi-threaded?
I’m interested in how it might perform at say 50,000 queries per second.
Earlier I have heard that ntpd development is lacking personnel. Why don’t those who behind ntpsec just join the original ntpd team and possibly take over the development?
Hello Alica. I’m the PM for the NTPsec Project. The relationship between NTPsec and the NTF is complex. We collaborate were we can, but we have no plans to “take over” the NTF.
1 Like
So far, all I had to do is to build with refclocks and docs (since I like manpages):
./waf configure --refclock=generic,shm,pps,local --enable-doc
./waf build
./waf install
After that everything was functional; I then changed the reflock definition from:
server 127.127.28.0 minpoll 4 maxpoll 4 iburst
fudge 127.127.28.0 time1 0.001 refid shm0
to:
refclock shm prefer minpoll 0 maxpoll 4
Still fiddling with new stuff to add, like statistics…
Do you have examples on how to set up the statistics stuff?
1 Like
I looked into NTPsec too. Seems really nice from an admin perspective. I do however currently just lazily use the default ubuntu/debian provided daemons and just go with the flow. And i suspect that as long as the bigger distro’s have such low entry barrier I suspect i’m not the only one sticking with what they know 
I don’t believe any of the open source NTP implementations are multi-threaded. Meinberg has a clever software solution to use multiple CPU cores in their SyncFire 1100.
They also have network cards that can do NTP “in hardware” for their IMS platform.
The appliance route can be expensive when compared to running VMs, however as you’ve noted there doesn’t yet seem to be any multithreaded NTP server implementations around.
I’ve had some success with running NTP in docker containers as a way of scaling out to use multiple cores on a box, however this assumes you are ok with using multiple IP’s to load balance the inbound requests.
Next up is to try running a load balancer to try scale NTP compute horizontally but behind the one IP.
Please check out: man ntpviz
My setup (I am running multiple Stratum 0 in the pool with ntpsec, git checkouts weekly:
logfile /var/www/html/ntp/ntpd.log
logconfig =syncall +clockall +peerall +sysall
statsdir /var/www/html/ntp/
filegen loopstats type day link
filegen peerstats type day link
filegen protostats type day link
filegen rawstats type day link
filegen sysstats type day link
filegen cryptostats type day link
driftfile /var/lib/ntp/ntp.drift
# Enable this if you want statistics to be logged.
statistics loopstats peerstats clockstats
Then run ntpviz, passing it the /var/www/html/ntp directory
1 Like
Debian switched with release 12 called Bookworm to NTPsec by default if the ntp package is installed. Before ntpd was used.
The only things I needed to do after the upgrade is to remove some ntpd leftovers and to align to the new ntpq statistic output.
So far the daemon is running fine and consumes a bit less CPU for the same amount of queries. I don’t have accurate numbers for this and also a lot if things changed in parallel (Kernel, Libs, …).
It using less CPU “per query” is indeed interesting. How much difference is it? Are you measuring both queries per second and the CPU per process?
Unfortunately I don’t have accurate numbers because I don’t save statistics per process.
Doing apt install ntp on Debian 12 will get you ntpsec.
Seems to work well 
pool.ntp.org: Statistics for 2a0d:5600:30:3e::bade