[ntp:questions] NTP client basic
David L. Mills
mills at udel.edu
Mon Mar 5 15:58:12 UTC 2007
The NTP on-wire protocol is inherently resistent to lost and duplicate
packets. See RFC 1305 for the definitive NTPv3 defenses. These defenses
continue in the current NTPv4. What articles you might find floating on
the web might or might not understand how these defenses work.
Peter Martinez wrote:
> Greetings to the list:
> I am an amateur programmer and a radio amateur. 18 months ago I needed to
> closely control the clock on my PC for a radio-monitoring application, and
> wrote an NTP synchroniser with Delphi, using an NTP component I found on the
> internet. It's been running perfectly since then, keeping the clock within
> 10mS rms.
> Recently a friend in another part of Europe wanted to do the same, so I sent
> him my effort. To my surprise it went crazy, tweeking the clock to crazy
> times and rates, and locking itself up.
> To cut a long story short, I discovered that there were duplicate NTP
> requests reaching the server, and the duplicate replies were getting
> mixed-up. I dug deep into the source code of the NTP component, and although
> I couldn't find the cause of the duplicates, I realised the thing was not
> well written and would malfunction if it encountered a repeat NTP reply. I
> wrote my own, working from RFC2030 and using a Delphi UDP component.
> That suffered the same problem. I now know that the UDP protocol which
> underlies NTP, is NOT guaranteed to prevent duplicates. I therefore had to
> take steps in my code to detect and suppress them. The NTP client component
> I had used previously had taken no account of this. RFC2030 only hints at
> the problem. I am amazed.
> My questions are therefore:
> 1) Do ALL good NTP clients take steps to suppress duplicate requests and/or
> replies, or do they survive by assuming that they don't occur very often? My
> original survived 18 months without being hit, but my friend in Belgium was
> hit by 1 repeat in 1000 or so, which rendered the NTP process unusable.
> 2) Knowing that the UDP protocol can produce spurious repeats, I would have
> thought the NTP server could detect them and suppress the repeated replies.
> Do they do this or am I being naive?
> 3) Does anyone have any figures for the incidence of UDP repeats? What sort
> of delay would one expect between the original and the repeat? I am seeing
> figures of 5 minutes or more, which really surprises me. Maybe my friend
> has a particularly noisy ADSL connection.
> 4) What's the usual way of suppressing duplicate replies? Comparing a local
> copy of the request's xmit timestamp with the reply's orig. timestamp seems
> the obvious.
> If these questions have come to the wrong place, would some kind soul point
> it (or me) in a better direction.
> Peter Martinez
> NorthWest UK.
> questions mailing list
> questions at lists.ntp.isc.org
More information about the questions