[time] limiting client requests in NTP 4.2.0

Paul-Andrew Joseph Miseiko esoteric
Mon Nov 17 19:39:41 UTC 2003

If you want to take into account ntpdate before ntpd then keep in mind some
people like to set ntpdate to burst 8 packets rather then 4.  This would
skew the rate-limiting algorithm even more.

Now also keep in mind it is a more acceptable practice to call ntpd -q
before ntpd if you wish to reset the clock before initializing the daemon;
but it is an acceptable argument that we can not educate the masses; though
this would get ride of the ntpdate before ntpd scenario.

If ntpdate sends 4 packets, and ntpd sends 6 at a poll of 6.  10 packets
(assuming ntpdate sends all 4 packets instantaneously, and ntpd sends its
packet immediately after ntpdate) would be sent in 320 seconds, 32 seconds
would be the average if ntpdate was used before ntpd.

-----Original Message-----
From: timekeepers-bounces at fortytwo.ch
[mailto:timekeepers-bounces at fortytwo.ch] On Behalf Of Alan Watson
Sent: November 17, 2003 12:52 PM
To: timekeepers at fortytwo.ch
Subject: Re: [time] limiting client requests in NTP 4.2.0

Thanks for your replies.

> I haven't familiarized myself with the 4.2.0 rate limiting features

Here's a summary of how the limiting feature works, based on a quick
reading of ntpd/ntp_restrict.c and ntpd/ntp_monitor.c:

  By default, clients/networks are not limited. You specify that a
  client/network is limited by adding "limited" to an appropriate
  "restrict" directive.

  By default, the limit on the average interval is 5 seconds and the
  limit on the minimum interval is 1 second. You can change these limits
  using a "restrict average X minimum Y" directive in ntp.conf. X and Y
  are measured in seconds and should be integral.

  By default, requests from clients that exceed limits are simply
  dropped. You can arrange for clients to receive a kiss-of-death by
  adding "kod" to the an appropriate "restrict" directive.

  When a request is received:

    It is matched to a history of previous requests according to the
    originating addresses without reference to the originating ports.
    (So, all requests from behind the same NAT-firewall appear to come
    from the same client.) This history includes the time of the last
    request and the average interval between requests.

    The interval since the last request is calculated. The average
    interval is updated according to:

      average_interval += (interval_since_last_request - average_interval) /

    This acts as a sort of windowing filter. With a constant request
    rate, it will asymptotically tend to the true average interval, but
    if the request rate is varying, it acts to smooth changes. For
    example, in my calculation yesterday I ignored it, but taking it
    into account implies the 10th request from a client that uses
    ntpdate and then a minpoll of 6 might arrive when the average
    interval is only 30 seconds. This means that even my supposedly
    conservative limit of 34 seconds on the average might drop a packet
    or two from this client.

    The first 9 packets are allowed regardless. After that, the average
    interval and the interval since the last request are compared to the
    limits. If a limit exceeded, either the request is ignored or a RATE
    kiss-of-death is returned. 

    Sending a kiss-of-death seems a bit extreme. If I understand it
    correctly, it effectively denies service until the server is
    restarted, regardless of the subsequent behaviour of the client.

    If requests are simply being ignored and the client backs off, it
    should eventually not exceed the limits and service will be resumed.

> Anothing thing is clients coming from behind a NAT-firewall.

Good point. If my server were used only via pool.ntp.org and if all
resolvers rotated addresses, I would not expect to see more than one
request from each network. However, I'm also happy for people to
statically configure my server, and if it happens to be a good one for
them, I have no problem with them using it several times behind the same
firewell. (We have three NTP stratum-3 servers behind our NAT-firewall,
and they have several external stratum-2 servers in common.)

I'm now inclined not to configure limits. I only have a handful of
clients apparently exceeding a minpoll of 6, and there seems to be too
much danger of denying service to two or three otherwise well-behaved
clients requesting service from behind a NAT-firewall.


Dr Alan Watson
Centro de Radioastronom?a y Astrof?sica UNAM
timekeepers mailing list
timekeepers at fortytwo.ch

More information about the pool mailing list