[ntp:questions] very slow convergence of ntp to correct time.

David L. Mills mills at udel.edu
Mon Jan 28 21:16:21 UTC 2008


You might have missed my message about rate control on the hackers list. 
The average headway for all packets, including those in a burst is 
strictly controlled at 16 s. So, 1 packet in a "burst" at 16 s, 2 at 32 
s, 4 at 64 and 8 at 128 s and higher. The default average headway can be 
set by a configuration command.

The scheme is specifically designed for long, noisy Internet paths and 
large poll intervals where the clock filter is most effective and also 
for cases involving dialup links with highly variable call setup delays. 
The fact that it trounces ARP caches is a secondary benefit.

ICMP pings will not work to our campus machines from outside. ICMP 
request messages are dropped by the ingress router.


Steve Kostecke wrote:
> On 2008-01-28, David L. Mills <mills at udel.edu> wrote:
>>Eric wrote:
>>>[---=| TOFU protection by t-prot: 72 lines snipped |=---]
>>That case and the ones you describe are exactly what the NTP burst
>>mode is designed for. The first packet in the burst carves the caches
>>all along the route and back. The clock filter algorithm tosses it out
>>in favor of the remaining packets in the burst. No ICMP is needed or
> Burst sends 8x packets to the remote time server at each poll interval.
> This greatly increases the load posed any one client.
> Perhaps it may be useful to allow the user to specify a smaller number
> of packets.

More information about the questions mailing list