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

Harlan Stenn stenn at ntp.org
Sat Oct 18 05:48:34 UTC 2008


>>> In article <gd806o$c6i$2 at usenet01.boi.hp.com>, Rick Jones <rick.jones2 at hp.com> writes:

Rick> Harlan Stenn <stenn at ntp.org> wrote:
>> It seems to me a topic related to initially getting the time set on a box
>> is the ability to determine the 'synchronization status' of ntpd.

>> Toward that end, http://support.ntp.org/bin/view/Dev/NtpdsSyncStatus has
>> been created.

>> I'd appreciate folks taking a look at that page, commenting and
>> discussing the issues.

That page says:
 The definition of 'correct' time

 How about the following:

 * The decoded system status bits contain sync_ntp
 * (obsolete) ntpd is in state S_SYNC (which Dave is renaming to EVNT_SYNC)
 * any slew adjustment in-process is under X (where X is configurable)

 * Do we care about the root dispersion?

Rick> If this is in the context of a quick, initial time setting I would
Rick> wonder if I (for some number of I's) "really" care if none of the time
Rick> sources I ask aren't yet synced?  I'm wondering if being set to a time
Rick> close to that of an unsynced server above me in the tree is better
Rick> than no time setting at all.

The definition is general.

If your time sources are not sync'd, how can they offer time to the client?

The rest of your choices are "local policy", as best I can tell.

-- 
Harlan Stenn <stenn at ntp.org>
http://ntpforum.isc.org  - be a member!




More information about the questions mailing list