[ntp:questions] Re: uk pool problem

Richard B. Gilbert rgilbert88 at comcast.net
Sun Sep 3 03:08:49 UTC 2006

Harlan Stenn wrote:
>>>>In article <edcja5$129$1 at hedeland.org>, per at hedeland.org (Per Hedeland) writes:
> Per> In article <ywn9y7t2hngo.fsf at ntp1.isc.org> Harlan Stenn
> Per> <stenn at ntp.isc.org> writes:
> Per> So is it deprecated or not? If it is, it would seem very strange to
> Per> consider enhancements (which was the point of my tongue-in-cheek
> Per> question earlier). Or are you saying that the *only* reason it is
> Per> deprecated is that there is no maintainer? That would certainly be
> Per> news...
> We looked for a maintainer for a Long Time and nobody stepped forward.
> Dave looked at the problems with ntpdate and decided he could address the
> majority of them with new features to ntpd (things like -q, -g, and iburst,
> to name just a few).
> Therefore we decided to deprecate ntpdate since the vast majority of the
> functionality existed elsewhere (and nobody was stepping up to fix ntpdate).
> I created http://ntp.isc.org/Dev/DeprecatingNtpdate over a year ago so we
> could have a place to collect discussion on this matter.
> I do not remember how long it has been that we have been telling folks that
> ntpdate is broken and nobody wants to fix it.
> ntpdate was written before there even was an sntp, and I have been telling
> folks for a long time that after we had a working sntp we would, to the best
> of my knowledge, have complete replacment functionality for ntpdate with the
> combination of ntpd and sntp.
> It has only been recently that anybody has asked for the -u option.
> Per> FWIW, I can see several objectively valid reasons to deprecate ntpdate,
> Per> and even a subjective one like "we don't like it" would have to be
> Per> considered valid - obviously no one can *demand* that you support some
> Per> particular piece of software (at least not without handing over money).
> :)
> Per> The problem that I see, and that leads to this tiresome re-hashing, is
> Per> that the arguments brought forward by those that want to have ntpdate
> Per> deprecated are almost uniformly bogus - like the absurd suggestion in
> Per> this thread that even though ntpdate allows you to specify multiple
> Per> servers, it wouldn't "do anything special" if one of them was 6 years
> Per> behind the others. This of course leaves you wondering if the desire to
> Per> deprecate ntpdate is actually based on nothing but ignorance.
> The last time I checked, both ntpdate and sntp will believe the first answer
> they get back.  I bet this is not *strictly* true, but I recall it was
> good enough.
> Per> Now you are saying that ntpdate has lots of problems - I can't really
> Per> deny that, but that's at least in part because I don't know what you're
> Per> refering to.
> Me either.  The problems with ntpdate have probably not been put into
> bugzilla because we have been telling folks for a long time now that we're
> gonna deprecate it and they should either:
> - use sntp if they want to set the time quickly even if the time is wrong,
>   just like ntpdate
> - use 'ntpd -g' with a good drift file and with 'iburst' if they want the
>   system time set correctly with the clock sync'd and ready to go (in about
>   11 seconds' time)
> Per> If it's just those listed on bugzilla, I'll have to say
> Per> that I couldn't find anything significant in need of a fix there (I can
> Per> elaborate if wanted). But maybe you're thinking of other problems?
> Yes, and I have way better things to do than to dig thru the archives
> looking for problems with ntpdate.
> So to summarize:
> - I have the belief that ntpdate is broken
> - Dave says that ntpdate is not needed anymore (and may, too, believe
>   ntpdate is broken)
> - nobody has offered to be the maintainer for ntpdate
> - we believe we have the needed functionality to do the things ntpdate
>   is *supposed* to do, and do it as well or better
> and therefore I believe the following are reasonably possibilities:
> - somebody can step up and take over the care/feeding of ntpdate
>   (this *might* be 'sufficient' to avoid the deprecation, but it is
>   certainly 'necessary')
> - - I suspect it will be much better to have the "next" ntpdate be a
>     shell script that calls either ntpdate or sntp with the needed args
> - somebody can tell us (open a bugzilla item, please) about something
>   that ntpdate does that the current ntpd/sntp combo does not do.
> H

I recall using ntpdate to correct a Solaris 8 X86 workstation that was 
off by more than eleven hours and do it by slewing the clock.  Yes, it 
took days to get the clock synched up but it was done without rebooting 
the work station or jumping the clock.  Ntpd could maybe do that but not 
as easily.  After I got it straightened out, ntpd kept it within a 
millisecond or so of the servers.

More information about the questions mailing list