Martin, 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. Dave Martin Burnicki wrote: > Dave, > > David L. Mills wrote: > >>Serge, >> >>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 _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
