[ntp:questions] ntpdate.c unsafe buffer write
David L. Mills
mills at udel.edu
Tue Feb 12 14:44:03 UTC 2008
No, there is no random delay at startup. Each association starts one
second after the previous one. The random backoff occurs only after a
step. The fact that the initial backoff is small means that the client
population is crudely synchronized and could well gang up after a step.
There have been incremental changes over the years to randomize and even
out the load for busy servers, some of which made folks sad. Originally,
the code did randomize at startup, but folks hated that since it
resulted in an initial delay averaging 30 s. Now the backoff occurs only
when stepped, which is by every measure a rare event. I don't think a
step has ever happend with our production servers, unless after
extensive downtime for repair.
You can easily modify the peer_clear() routine in ntp_proto.c to remove
the backoff. If so, you will not be able to use any server running the
reference implementation, as the rate violation will result in a dropped
packet and, if configured, a KoD.
Martin Burnicki wrote:
> David L. Mills wrote:
>>The behavior after a step is deliberate. The iburst volley after a step
>> is delayed a random fraction of the poll interval to avoid implosion
>>at a busy server. An additional delay may be enforced to avoid violating
>>the headway restrictions. This is not to protect your applications; it
>>is to protect the server.
> Is it really necessary to insert a random delay after a step? There has
> already been a random delay immediately after startup, before the client
> has decided that a step was required.
> So even if a bunch of clients started up at the same time and had to step,
> they wouln't step at the same time, and thus wouldn't do the next iburst
> volley at the same time anyway.
More information about the questions