[ntp:questions] NTP client basic

Danny Mayer mayer at ntp.isc.org
Sat Mar 3 11:57:14 UTC 2007

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.

What exactly do you mean by an NTP synchroniser? Is this just an NTP
client running on your system and just taking the received time and
using it to set the clock, does it adjust the clock frequency? What is
it doing? Also to you have an NTP server running on this system
separately from your NTP synchroniser?

> 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.

When you say they are duplicate requests and duplicate replies what
exactly do you mean by that? In what way are they duplicate? In what way
do they get mixed up?

> 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.

UDP won't retry a packet. Either it reaches its destination or it
doesn't. If it's being sent out again then it's in your own code.

> 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.

It's most likely in your own code but it's hard to tell without seeing
it. What does it do when it doesn't receive a response for example?

> 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?

No, UDP makes no attempt to repeat, spurious or otherwise. If it fails,
it fails. UDP does nothing about it.

> 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.

Then your code must be sending out duplicates. Why is it doing that?

> If these questions have come to the wrong place, would some kind soul point 
> it (or me) in a better direction.

This is the right place.


More information about the questions mailing list