[ntp:questions] "ntpd -q" is slow compared to ntpdate

David J Taylor david-taylor at blueyonder.neither-this-part.nor-this-bit.co.uk
Mon Oct 20 05:38:18 UTC 2008


Harlan Stenn wrote:
[]
> By my read and understanding of the RFC, SNTP as a protocol is
> designed to be used to set the time once, quickly, and ordinarily
> would not have an attached refclock (and therefore would not be a
> long-running daemon).
>
> Therefore, 'sntp' seems to me to be a perfectly good name for a
> program that does the work David describes.
>
> It also matches what has been implemented.
>
> I seem to be missing something you are seeing - what do you think the
> RFC expects from an SNTP implementation?  I'm talking about a
> client-only implementation, not a barebones "I'm talking to a
> refclock and will answer NTP queries" server.

Folks,

There are lots of "atomic time" programs out there which use SNTP as a 
protocol for setting the clock on a similar semi-continuous basis to the 
current NTPD program.  The difference is that they don't use multiple 
servers in the same way and the advanced phase and frequency algorithms of 
NTP to produce a more stable, accurate and relaible result.

These programs run continuously, and to have a program which ran once only 
and exited, but be called SNTP would, I think, be potentially rather 
confusing.

If you have such a once-off program, why not call it by a meaningful name?
Starter suggestions:

  ntpsnapshot
  sntpsnapshot
  ntpglance
  sntpglance
  remoteclocksnapshot
  timeglance
  clocksetandexit
  clockboot

Cheers,
David 





More information about the questions mailing list