In v4 we’re using the MQTT connection less, so I didn’t notice (though monitoring was squeaking!) that I broke the client connectivity. It is used for the “ad hoc NTP check” feature and for the first sanity check when adding a monitor, so that breaks when there are no more v3.8.6 monitors.
Upgrading to v4.0.5 fixes it (I upgraded a few monitors so the features above should work again).
Thanks to @msiegen for reporting this.
@ask was the build for 4.0.5 uploaded? I do not see it on Index of /ntppool-agent/builds/release
For “yum” users it seems to be available in the ntppool-test repository only.
Maybe https://builds.ntppool.dev/ntppool-agent/builds/test/579/checksums.txt helps?
Whoops – @avij is right it’s only in the testing repository. I forgot to hit “publish” to promote it as a proper build. It should be in the repositories now, and on
Up and running IPv4 only. Tell me what you expect.
As I have a new router, DrayTek and it CAN handle the requests, where the Fritzbox failed.
2 monitors in production, like the new system a lot!
But 1 remark, I tried to install from the github, but the apt-source was missing, maybe a good idea to link to it or mention it in the readme. Other then that, great job!
DrayTek seems to handle the load fine….where the Fritzbox started to crawl within the hour of running.
But then, these are not simple home-grade-routers 
I’m using a MikroTik RB3011 router myself for the NTP in Leuven, Belgium. It can do 2 million pkts/s with connection tracking. MikroTik has a so-called fasttrack function that offloads most of the network stack to hardware. As of now, my NTP does on average 1500 pkts/s so that’s “pocket change” 
Are you running this sever by any chance?
BTW, ntp.oma.be seems to have put all severs in a pool, like I do with ntp.heppen.be
nslookup ntp.oma.be
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: ntp.oma.be
Address: 193.190.230.106
Name: ntp.oma.be
Address: 193.190.230.105
Yes, that’s my NTP. I was wondering whether the oma ntp was undergoing maintenance or had other problems. Will update the config.
Seems Oma blocked the access to their Stratum1 servers, I tried to acces them but got thrown out.
So I switched to their pool.
I’m getting KoD from the second Oma server. chrony can’t use it at all, and no, nothing’s wrong on my side. The first Oma server has no issues.
Weird, as they both work fine here:
Last login: Sun Aug 31 17:43:03 2025 from 192.168.1.101
root@server:~# chronyc sourcestats
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
GPS 6 5 18 -560.883 3089.430 +4499us 5256us
PPS 37 17 72 -0.002 0.298 -1ns 10us
ntp0.nl.uu.net 15 9 275m +0.132 0.039 -1389us 166us
ptbtime1.ptb.de 17 6 293m +0.098 0.175 -3477us 954us
ntp-public-2.oma.be 11 7 241m +0.138 0.042 -2321us 122us
ntp-public-1.oma.be 7 5 138m +0.103 0.106 -2054us 92us
root@server:~# chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#- GPS 0 2 377 2 +7293us[+7293us] +/- 111ms
#* PPS 0 1 377 2 +1102ns[+1232ns] +/- 27us
^- ntp0.nl.uu.net 1 10 377 565 +1021us[+1083us] +/- 10ms
^- ptbtime1.ptb.de 1 10 277 22m -4957us[-4812us] +/- 16ms
^- ntp-public-2.oma.be 2 10 377 517 -1304us[-1249us] +/- 34ms
^- ntp-public-1.oma.be 2 10 377 1018 -2303us[-2188us] +/- 36ms
But then, I do not poll other sources that often, there is no use for it.
My setup:
# GPS time.
refclock SHM 0 refid GPS poll 2 precision 1e-3 offset 0.070 delay 0.2
refclock SHM 1 refid PPS poll 1 lock GPS precision 1e-8 maxlockage 64 prefer
#refclock PPS /dev/pps0 lock GPS refid PPS poll 1 precision 1e-8 maxlockage 64 prefer
#You do need to talk to an NTP server or two (or three).
server ntp0.nl.uu.net
server ptbtime1.ptb.de
pool ntp.oma.be
Beware, I use an RS-232 GPS, so I poll a bit faster, but just to show my workings.