[ntp:questions] NTP client basic

Per Hedeland per at hedeland.org
Sat Mar 3 11:27:11 UTC 2007

In article <017a01c75c3b$15cb2850$0300a8c0 at LAPTOP>
peter.martinez at btinternet.com (Peter Martinez) writes:
>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.

RFC 2030 does not describe NTP, but the in comparison very limited SNTP,
and it does mention a number of caveats on the use of SNTP.

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

NTP specifies sophisticated filtering algorithms that will cause all
"oddball" responses to be effectively ignored, there's no reason to take
the possibility of duplicate replies into special consideration. SNTP
does not do so, but I guess there is a (reasonable) assumption that
anyone implementing it will include at least basic sanity checks on the
packets received - and 2030 *does* mention this, even if you think it's
just a "hint". Believing a single packet that says that your time is 5
minutes off is not a good idea, regardless of the issue of duplicates -
and if the roundtrip calculation gives a result of the same magnitude,
that's of course a further indication that it should just be tossed.

>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, that would require a server to keep state for every client, which is
not desirable - it's up to the client to deal with the responses 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.

I don't have any numbers, but I would say that duplicates are extremely
rare, and probably always indicate faulty or misconfigured network
equipment. After all *something* must have transmitted the packet twice,
which is always the Wrong Thing to do for UDP. One case I can think of
would be a setup with Ethernet half/full duplex mismatch - a sender that
believes that the link is half duplex will see "false collisions" and
retransmit (at the Ethernet level), while the recipient operating in
full duplex mode may actually have received the packet just fine.

Of course this could not by itself result in a 5 minute delay - in fact
I have hard time coming up with anything other than intentionally
malicious acts that would. And this is certainly not a possibilty that
should be ignored.

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

Yes, this is a good sanity check. I don't know if it's "usual" since I
haven't studied the implementation of any SNTP clients. For NTP it's a
non-issue per above, and even some rudimentary filtering in the SNTP
case would have taken care of your problem - e.g. send (say) three
packets (adequately spaced) and use the average after tossing any
replies that are way off.

--Per Hedeland
per at hedeland.org

More information about the questions mailing list