[prev in list] [next in list] [prev in thread] [next in thread] 

List:       timekeepers
Subject:    [Pool] NTP rate limiting with chrony
From:       Miroslav Lichvar <mlichvar () redhat ! com>
Date:       2015-12-01 10:46:24
Message-ID: 20151201104624.GC9415 () localhost
[Download RAW message or body]

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
pool@lists.ntp.org
http://lists.ntp.org/listinfo/pool
[prev in list] [next in list] [prev in thread] [next in thread]