Re: NIST time
"Paul E Condon" <pecondon@quiknet.com> writes:
> Craig Dickson wrote:
>
> > Sam Varghese wrote:
> >
> > > i used ntpdate initially but have now swicthed to chrony. the same
> > > guy who wrote pppconfig has written this utility and like pppconfig
> > > it is simple and works well.
> >
> > Is ntpdate not simple, or does it not work well? What caused you to want
> > to switch? I use ntpdate and it seems to do the job nicely, but if there
> > is a real advantage to chrony, I might give it a try.
> >
> > Craig
> >
>
> My experience with this issue may be interesting to others...
>
> 1. ntp-simple does not exist in Packages.gz as downloaded today from
> ftp.us.debian.org
>
> 2. It was not clear from the messages in dselect that ntp.deb and
> ntpdate.deb are cryptically incompatible. Both need to listen on a
> particular socket that is dedicated to the NTP protocol. During rc2,
> ntpdate is run first and ntp is then started. This is fine, because
> ntpdate really doesn't start a deamon. It just runs ntpdate once to
> update the system clock, and then ntp deamon gets started. But if you
> try to run ntp from the command line, it gives an error message. So be
> sure NOT to install ntp.deb, if you want to be able the check your
> ntpdate installation from the command line.
I don't know if I'd use the word incompatible. The two are really
complimentary. They're designed to work as you stated. First you sync
with ntpdate and then start the ntp daemon to run continuously and
keep your clock in sync. In fact, if your time/date is too far off the
ntp daemon will refuse to reset your clock. That's one of the reasons
to run ntpdate prior to starting the ntp daemon, and once you're
running the ntp daemon there's no reason to run ntpdate. ntpdate is
used to get your clock in the ballpark, and the ntp daemon is designed
to keep it there. Also, I believe, the daemon doesn't make large
changes to the time, but instead incrementally adjusts your clock to
match the ntp server. ntpdate just sets your clock to the correct
time.
If you do install ntp before ntpdate, you can always:
/etc/init.d/ntp stop
/etc/init.d/ntpdate start
/etc/init.d/ntp start
> 3. My reading of stuff on the NIST time web site leads me to believe
> that NTP (the protocol) is poorly designed and obsolescent. But don't
> ask me to defend that. Read what they say, and draw your own
> conclusions.
I think it's more the case that it's serious overkill for someone that
just wants reasonable accuracy on his/her desktop system, like on the
order of milliseconds, instead of picoseconds. It's a very complex
protocol, from what I understand, but pretty accurate. Also, because
of it's complexity, it's become a nightmare to maintain/expand it's
features. From http://www.boulder.nist.gov/timefreq/service/its.htm:
The Network Time Protocol (NTP) is the most complex and
sophisticated of the time protocols, and the one that provides the
best performance.
> 4. Documentation for ntp indicates that the software has been updated
> with a view to working on future very fast LANs, very fast
> Internet. I, personnally, think this is a foolish waste of effort. The
> time information that is available from GPS will always be somewhat
> better, and never worse, than what is available via land lines and
> packet forwarding.
I guess I'm a little confused by this. I agree with the conjecture,
but how does the GPS time get translated to computer? Last time I
looked, admittedly a long time ago, hardware to perform such a
function was rather pricey.
I think the idea behind the development of the ntp protocol and the
software to support it was to work on fast LANs for organizations
where time accuracy/synchronization on/between computers is critical
to something they do. I don't think the idea behind it's design was to
sync your desktop computer at home. Just turns out it is (or was) the
only thing available to perform that function.
> IMO, the best next step in development of time on the internet would
> be to introduce a protocol that did not require a special socket
> assignment on the client. I think NIST has already made some progress
> on this (see point 3, above)
I agree here. Such a system makes much more sense for those of us
where picosecond accuracy isn't necessary. But ntp will certainly have
a role to play in other arenas.
Gary
Reply to: