[ntp:questions] SNTP with 1ms of precision?

Danny Mayer mayer at ntp.org
Thu Jul 8 11:49:47 UTC 2010

On 7/8/2010 2:50 AM, David Woolley wrote:
> Danny Mayer wrote:
>> On 6/16/2010 5:22 PM, Maarten Wiltink wrote:
>>> "Marcelo Pimenta" <marcelopimentacs at gmail.com> wrote in message
>>> news:AANLkTilQ6M8ApEoaSIbr-o8mhwiFqKFV9xyf6MUDraDt at mail.gmail.com...
>>> [...]
>>>> The NTP algorithm is much more complicated than the SNTP algorithm.
>>> The short, short version: there is no SNTP algorithm. SNTP is NTP
>>> _without_ the algorithms. Using NTP means continuously adjusting the
>>> speed of your clock so it tracks real time as best you can make it,
>>> while SNTP is simply asking what time [they think] it is.
>> This is a totally inaccurate statement. See RFC 5905 Section 14. SNTP is
> That RFC was published after this thread was started! You can't go
> changing the definitions just for you convenience.  Even if it had been
> published, say six months earlier, the reality is that de facto and
> historic definitions would still dominate the market.

RFC 2030, which RFC5905 obsoleted, said the same thing. It doesn't
change anything that I've said. I'm now using RFC 5905 because that's
what we should be referring to as of now but it merely documents the
status of the protocol and doesn't change it in any substantial way.

>> merely a subset of the full NTP protocol. An SNTP server is one with
>> it's own refclock and not dependent on any other upstream servers while
>> and SNTP client is one with a single upstream server and no dependent
>> clients. An SNTP client or an SNTP server should be disciplining the
>> clock in the same way as an NTP server. An SNTP server should
>> continuously adjust the speed of your clock otherwise it's not SNTP
>> compliant.
> In reality, most SNTP clients step the clock.  A few may use a simple
> frequency control scheme.  Once you go much beyond that, it becomes
> simpler to use a full NTP client, but maybe configure only one server.

That's not an SNTP client despite people's attempts to call it that, see

> In fact, RFC 1305 doesn't require any specific clock discipline for
> NTPv3 clients; that is in an appendix, rather than in the main
> specification.
> The important clarification about SNTP, ignoring any recent attempt to
> redefine it, is that it doesn't specify an algorithm, rather than that
> it requires the use of only a trivial algorithm.

There has been no attempt to redefine SNTP. RFC 2030 is 15 years old so
it's hardly recent. Tools like ntpdate are not SNTP clients by the
definitions of any RFC you care to name, it just sets the clock. SNTP is
a simplified protocol to discipline the clock and not just set it.


More information about the questions mailing list