[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:
> Dave,
> 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.
> Martin

More information about the questions mailing list