Re: NIST time
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.
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.
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.
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)
Reply to: