Thanks @MagicNTP for your assistance. Much appreciated. My experience with server-owner-help@ntppool.org has not been great in the past. Numerous emails with requests have gone unanswered for past few years… Hopefully @apuls or @Knot3n can assist.
Yes, same here. I was really surprised to see my request on this, and a server zone correction I submitted around the same time, go through this time, but obviously am very grateful they did, thanks!
Still, I am not sure why it is this way, because it doesn’t have to be this way, needlessly causing frustration and bad user experience on the part of volunteer server operators.
E.g., if it is a shortage of staff, I am sure another volunteer or two would be willing to lend a hand to fill the gap, and not let more requests fall through the cracks than get actually processed, and seemingly at random.
1 Like
As @MagicNTP wrote, please use server-owner-help@ntppool.org everytime you have question or need change setting so it can be tracked and maybe other volunters can check it.
Just my 2 cent
Regarding the BE zone i would say the same as the other thread about those zones (CN / RU / PH)
- if the amount of request raised from one day to another, it could make sense to do pcap and check if some clients may abuse the pool (keyword: Fortigate FW, Viessman Central Heating, Devolo Powerline Adapter, etc … ). In this case you should get in contact with @stevesommars
- check if your ISP provide an ntp server and if it’s in the pool. When it’s not in the pool contact you ISP and ask why not.
- Check university websites if they provide ntp server and if those are in the pool. When not contact them and ask why.
In short: make the need of joining the pool public !
It took me 15 min to find public websites which provide public ntp server which aren’t in the pool
1 Like
You can’t as the speed-settings does nothing unless you select world.
It’s something @ask has to fix in the way he distributes requests via DNS.
NL/DE/FR/etc have enough servers to cover Europe, yet they do not help BE.
@Bas I am aware of this. therefore i have an outstanding request to assign my server to the BE zone. No response yet, however.
I have enabled my server again, maybe the change of ISP makes a difference.
We will see.
My DrayTek modem/router does tell me loads of 123 sessions all the time.
Also Chrony drops a lot of packages.
Let’s see how it goes.
Ideally you’d configure your router to not track NTP “sessions” (UDP 123 “connections”). NTP uses UDP as intended, connectionless, and the session tracking is just making the router a potential bottleneck with no functional benefit.
If you can reach below the GUI to some sort of command line, you might be able to configure the NAT software that way.
1 Like
I turned it on to track them, to see the data-session-flow.
They where turned off.
UTP is Send-And-Forget, I know that. But I’m DDOS’ed at NTP traffic because of the pool.
Too much requests, too little servers and the pool does not let EU-servers help.
The problem is the pool itself, the DNS-data-rate is flawed. Did you read any of the topic?
Now that you have your NTP server running again, it would be really nice to see actual NTP query rates. This should still do the trick:
(chronyc serverstats; sleep 1h; chronyc serverstats) | grep “NTP packets received”
Thinking further, this will only show the number of NTP queries that reach your NTP server. The NTP queries that get dropped at your router will not be visible in these numbers. But I’d think any numbers would be better than nothing.
Done, this is the number after 1 hour:
root@server:~# (chronyc serverstats; sleep 1h; chronyc serverstats) | grep ‘NTP packets received’
NTP packets received : 936963
NTP packets received : 978481
978481-936963=41518 received/hour
That doesn’t seem much to me.
NTP packets dropped : 16130
NTP packets dropped : 17468
But it did drop quite a few. Maybe that’s the problem?
However, I see the number rising every 20 minutes or so.
Start test: 3.672 / 3.753 / 3.780 and going up.
It could be it takes time to become more ‘active’ in the pool.
Or did something change? As I watched the be.pool.ntp.org for a bit and didn’t see my IP popup.
Yet it is listed as active.
Update: 3.903 number now….
Update2: 3.936 number rising.
Hi Bas, wanted you to know i am contributing to the BE zone with an additional IPv6 server (which also serves the NL zone).
While it is still settling in, I see a reasonable amount of traffic already. Currently around 340 queries/s (combined load for NL and BE) while bandwidth setting is around 1Gbit.
be 163.259 ‱ | 761.528 ‱ (0.21x)
nl 11.876 ‱ | 60.604 ‱ (0.20x)
Looks like the bandwidth i am contributing is 1.6% of queries and 7.6% of the total BE bandwith.
I’m unsure if this only applies to IPv6 or if its combined bandwidth.
Maybe some of the traffic you were seeing before is now routed to me. 
2 Likes
Yes, 11.5 queries per second (41518 per hour) is not particularly much. It may increase slighty in the next few days, but it’ll probably remain in the same ballpark.
I wouldn’t be concerned about dropped packets as reported by chrony. It’s just rate limiting in action. Of the 41518 packets received 1338 were dropped. This is around 3.22%.
On my production servers the dropped packet rates are (since daemon startup):
fi: 4.35%
nl: 6.74%
cn: 6.28%
sg: 4.61%
fi and nl servers use “ratelimit interval 3 burst 8 leak 2” whereas cn and sg servers use “ratelimit interval 3 burst 8 leak 4”. The differences in the leak parameter are not really intentional, but that’s how they’re apparently configured right now. interval 3 and burst 8 are the defaults but I like to write the numbers in my config anyway. The default for leak is 2.
Do note that the “ratelimit” limits requests coming from each IP address separately. Well-behaving clients (like NTP pool monitors) are not affected by the usual rate limits, but those IP addresses that send more frequent queries will notice that some of their queries get dropped.
All in all, I don’t see any signs of a DDoS yet.
And it goes up….
| be | 7.508 ‱ | 0.271 ‱ (27.75x) |
|---|---|---|
Double from yesterday.
Last login: Tue Oct 14 15:45:32 2025 from 192.168.1.107
root@server:~# (chronyc serverstats; sleep 1h; chronyc serverstats) | grep ‘NTP packets received’
NTP packets received : 2002742
NTP packets received : 2046073
43331 per hour, that is not double like the pool-page shows.
Very weird.
Thanks man! But you are hit hard, way more then NL.
That is what I mean, Belgium is underserved. As soon as a sever enters it gets massive numbers, way more then a server does in other countries.
As your own stats show.
Yes indeed, but i’m happy to help out.
hopefully this helps you out also. Weird stats you are showing by the way.
Has anyone taken a TCP dump or looked at Chrony stats regarding misbehaving clients?
how do i look at chrony stats?
i tried the command above but this didn’t work for me.
Quoting Ask in the other topic:
The traffic permyriad (the first number) is over the last 48-72 hours (last 3 24 hour periods, including the current day UTC); the netspeed permyriad (second number) is “real time” (minus some ~30 minute caching on the CDN), so the ratio is inaccurate for a few days after changing the netspeed.
So it will take a few days for the pool DNS query stats to stabilize. As of now the number seems to be 7.683 ‱ (0.07683%). If all the 28 Belgian pool NTP were included in the pool DNS equally, each would get 3.57% of the requests. Considering this, I would say 0.07683% is a very reasonable number for a 512Kbit/s pool server in the Belgian zone. The sky is definitely not falling.
Comparing these DNS query stats between zones is… I’m tempted to say pointless, but it’s a far less useful metric than the NTP query rates. NTP query rates are universal, but the DNS query stats depend on the total amount of queries in the zone and the total number of servers in the zone. Especially one should not file claims of a DDoS based on these DNS query rates alone.
“Extraordinary claims (of a DDoS) require extraordinary evidence”, which quoting the DNS query rates is not.
Kets_One: As for “chronyc serverstats” not working, you may need to run it as root. If it “does not work”, some output from the “chronyc serverstats” command would surely help with diagnostics.
2 Likes
The NTP servers I am maintaining are recently added to the be zone (thanks), and the traffic growth is visible:
@NTPman Are these numbers combined traffic for IPv4 and IPv6?
0.ntppool.itu.ch resolves in both A and AAAA addresses.
What is the netspeed you have set?