[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