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

Unruh unruh-spam at physics.ubc.ca
Sun Oct 19 17:33:49 UTC 2008

David Woolley <david at ex.djwhome.demon.co.uk.invalid> writes:

>Steve Kostecke wrote:

>> This discussion dates back to August, 2002.
>> Please see
>> http://groups.google.com/group/comp.protocols.time.ntp/msg/3387eda49518407a?dmode=source
>The argument there seems to be not that ntpdate is worse than SNTP, but 
>that there is an implied promise that it is almost as good as ntpd.  The 
>reason for having SNTP is to have something which has no pretensions of 
>being anything other than crude.

??? The rfc on sntp seems to say that sntp should be just as good as ntp in
disciplining a local clock, it just should not be used as a server (
uneless it gets its time from an atomic clock). Ie, the promises for sntp
seem far stronger than for ntpdate. ntpdate makes no promise to discipline
the frequency of a computer's clock. sntp does as far as I can see. 

The claim is that ntpdate should be retired because a) it is written in a
way which is hard to maintain, and  support, and b) it is flawed. The first
is a perfectly valid concern. The second I would like to know how it is
flawed. AFAIK all it does is to set the local clock to the time as
determined via ntp packet exchange from some server. it does not set the
frequency, it just sets the time. Is there some flaw in the way in which it
sets the time? Could I run ntpdate with a reliable server as a source and
suddenly discover that my local clock is out by 79 days, or that the
frequency has been reset to 1 tick per century? Ie, is there a flaw in what
it claims to do?

More information about the questions mailing list