The latest development code of chrony in git now supports response rate limiting. I was wondering if someone from the pool.ntp.org members that are running chrony on their servers would be interested in early testing to see how well it works on public servers.
It includes a detection of clients that don't like to be rate limited and actually increase their polling rate when the server is dropping their requests. Such clients should get replies to most of their requests to keep them happy and not increase the overall network traffic. If you know you have clients like that and you are willing to test the new code, please check if the feature works as expected for them. It can be enabled by adding "ratelimit" to chrony.conf. The default minimum allowed polling interval is 3 (8 seconds) and 8 packets are allowed to be sent in a burst. You can change the parameters in the ratelimit directive, e.g. with 32 second interval and only 4 packets in the burst it would be: ratelimit interval 5 burst 4 The default clientloglimit allows monitoring of up to 4096 clients. On a busy public server that's probably not enough and you may want to give chronyd more memory for the client log, maybe 10 MB or even more: clientloglimit 10000000 To get a list of addresses sorted by number of received packets: # chronyc -n clients | tail -n +3 | sort -r -n -k 2 And sorted by their polling interval: # chronyc -n clients | tail -n +3 | sort -n -k 4 There is also a cmdratelimit directive to enable rate limiting for the command packets, but I'm not sure if anyone has allowed commands from internet and has a lot of clients using that. The configuration would need to be adjusted for the expected use, some commands require only one packet, others are bursty. If you see anything odd or have suggestions for further improvements, please let me know. -- Miroslav Lichvar _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
