[ntp:hackers] ntpdate removal is coming

Warner Losh imp at bsdimp.com
Mon Jul 25 23:39:05 UTC 2011

On Jul 24, 2011, at 12:44 AM, Harlan Stenn wrote:
> My preference is that we make sure we get rid of the need to set the
> clock before starting ntpd.

Honestly, I tend to agree.  There's some interesting effects that old-versions of ntpd exhibited that forced use of ntpdate.

ntpd will need to set a "sane" system time quickly too.  "sane" here means "close enough that you won't do a time phase step." With the usual caveats that the underlying clock has to be "sane" as well.  Note that "sane" here is a much loser definition than ntpd uses to get things up and going well.  it just means that the phase error and frequency error of the system are low enough that ntpd will start normally without jumping time.  Maybe "loosely coupled" to the remote vs "locked" to the remove might be a better way of phrasing.

The main reason we used ntpdate in our products was to get the system time close before we started control programs, GUIs, etc.  Also, getting the time phase "rough and ready" in a couple of seconds was far preferable to having time phase and frequency "perfect" in minutes.  Also, the initial phase jump with few programs already running had other nice effects (we started the bulk of the programs after it, just for reference).  ntpd behaved nicer, as described elsewhere in this thread, and our control programs did great so long as there was no step in time (so started after the ntpdate they were simpler to write since we didn't have to put goo in to wait for good time, nor did we have to clutter the fast paths with time could change code).  ntpdate got us to the point where nearly always things worked quickly.  "nearly" here was operationally good enough, but sometimes it fell down when the remote hosts were down, misconfigured or otherwise in error.  In those cases we could note that ntpdate failed and take appropriate action to go into a hold-over mode pending the return of ntpd or some other application specific recovery.  With ntpdate on startup, we could discover this situation more quickly than ntpd would report it as well.

So long as these actions are possible with ntpd -q, or similar thing, and so long as the elapsed time to get as good as or better results than ntpdate is comparable (to cover the seconds not minutes issue), ntpdate can go.

Again, my apologies if all these issues have been fixed in latter-day ntpd versions.


More information about the hackers mailing list