# The issue of NTP requests exceeding bandwidth load **URL:** \ **Category:** Server operators\ **Created:** [November 3, 2024, 10:32am UTC](https://community.ntppool.org/t/the-issue-of-ntp-requests-exceeding-bandwidth-load/3588 "2024-11-03T10:32:18Z")\ **Posts on this page:** 1\ **Showing post:** 12
**Author:** ![PoolMUC](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/poolmuc/32/1473_2.png) [@PoolMUC](https://community.ntppool.org/u/PoolMUC)\ **Post date:** [November 4, 2024, 9:25pm UTC](https://community.ntppool.org/t/the-issue-of-ntp-requests-exceeding-bandwidth-load/3588/12 "2024-11-04T21:25:55Z")
> [@summer76527](#): > > already canceled the deletion request and set it to “monitor-only Good, thanks! The score trend visible is very interesting. There’s a few monitors that have issues, but there is a sufficient number that work well enough to keep an almost perfect score. That seems to suggest that the issue with low scoring is (likely) _not_ due to the location of the monitors and their traffic crossing international connections. > [@summer76527](#): > > there are still NTP requests Yes, “full” NTP clients (e.g., chronyd, NTP classic, NTPsec), often running on servers or PCs, will keep polling a server for a while after initially getting the IP address of a server. They have mechanisms to continually track upstream servers, and to make continuous corrections to the local clock (called “disciplining” the clock) so it is smooth without jumps in time. That is why they hold on to the IP addresses they got initially across multiple queries to the upstream servers. That is what you are still seeing. The IoT devices you mention tend to implement a simpler version of NTP called SNTP. Those typically don’t continuously adjust their clocks, but poll upstream servers periodically, and then set the time according to that. That entails that when configured with a DNS name pointing to the pool, they keep re-resolving that each time, and depending on the timing, get different IP addresses every time. So when a server leaves the pool, it will not get any requests from this type of client anymore. But also non-IoT devices may have an SNTP client only, e.g., older versions of MS Windows (newer versions have “[high precision timekeeping](https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/configuring-systems-for-high-accuracy)” support, which sounds like a full(er) NTP implementation), or systemd-timesyncd becoming more common on Linux. > [@summer76527](#): > > currently don’t have any points I encourage you (and others) to [set up your own RIPE Atlas software probe](https://github.com/RIPE-NCC/ripe-atlas-software-probe/blob/master/INSTALL.rst). You can earn points that way to eventually run your own tests, but you also help improve the coverage of the RIPE Atlas project so it becomes more useful for investigations like ours. The additional load, both CPU as well as network wise, is rather small, and the network throughput can be limited to as low as 10 kbit/s. Only thing is that the tools are currently a tad chatty as far as system logging is concerned… > [@summer76527](#): > > correlation between ping and NTP quality at the **network transmission** level It really depends on circumstances. Pings _can_ be a good rough indicator of network transmission conditions that also NTP packets will encounter, but that always needs to be taken with a grain of salt. Obviously, ICMP is not NTP, so network operators may treat them differently, and, e.g., ping does not assess the performance of the NTP server itself, e.g., whether it is overloaded or otherwise dropping packets (e.g., rate limiting). So if one sees some network transmission behavior for ICMP, it is _likely_ that also NTP might be affected, or vice versa, giving an _indication_ as to how to potentially proceed further in the investigation. Always keeping in mind that it might also be quite different. Case in point: While the NTP measurement to [time2.cloud.tencent.com](http://time2.cloud.tencent.com) clearly shows packet loss, a [ping measurement from the same four original vantage points](https://atlas.ripe.net/latencymon/80927490/) as the original NTP measurement doesn’t indicate any relevant level of packet loss. In other cases, the [correlation is nicely visible](https://community.ntppool.org/t/disable-monitoring-emails-for-a-single-server/3577/12). Since it is quite easy to use, this is typically the first tool I use when troubleshooting a wide range of networking issues (provided the target hopefully doesn’t block it). > [@summer76527](#): > > my server has not experienced any form of failure in the past 24 hours Sorry, I didn’t mean to imply there to be anything wrong with your server. This can simply happen if two network operators don’t cooperate very well, or some operator implements some filtering of NTP traffic (there was a time when NTP servers could be abused for amplification attacks). E.g., my Alibaba-hosted server in Singapore for some reason seems [unreachable from the monitor in Finland](https://www.ntppool.org/scores/47.236.162.36/), at least via NTP. > [@summer76527](#): > > see if there is a correlation between traffic peaks and time periods Good idea, looking forward to the outcome of the experiment. I hope 10 Mbps will be sufficient to cope with the potential peaks you’ll see, keeping my fingers crossed 🤞 🙂 [Variations in the Singapore zone are quite pronounced during the daily cycle](https://community.ntppool.org/t/disable-monitoring-emails-for-a-single-server/3577/15). There’s been a [proposal for an API](https://community.ntppool.org/t/api-for-changing-server-speed/3080) to be able to programatically control the “netspeed” setting, e.g., to automatically manage traffic volume/rate in the face of bandwidth limits/traffic quotas. But the right combination of know-how and resources/time wasn’t available so far to make that happen. Kind of a sledgehammer method to regulate the load on a server would be to [expressly use the monitoring system for that purpose](https://community.ntppool.org/t/adding-servers-to-the-china-zone/88/247), like it anyhow implictly regulates the traffic by dropping servers from the pool when they get overloaded. A bit more difficult to use these days, now that we (thankfully) have a much larger and diverse set of monitors. And the feedback loop might be a bit too slow in severely underserved zones if traffic rate shall be managed (i.e., when there isn’t a “hard” bandwidth limitation, but, e.g., too high bitrate could trigger protection mechanisms). > [@summer76527](#): > > non-native English speaker Same here 😉 > [@summer76527](#): > > please ignore my grammar mistake No worries! 😁 --- _[View the full topic](https://community.ntppool.org/t/the-issue-of-ntp-requests-exceeding-bandwidth-load/3588)._