David Woolley wrote:
> Richard B. Gilbert wrote:
>
>>
>> I don't recall that +/- 128ms is specified anywhere. If ntpd gets
>> it's initial time from a hardware reference clock, the time SHOULD be
>> very close. This will, off course, depend on the latencies in the
>> reference clock's response and the resolution of the time supplied.
>> <snip>
>
>
> This is where it is documented in the source code for 4.2.4p4
> (ntpd/loopfilter.c):
>
> * State < step > step Comments
> * ====================================================
> * NSET FREQ step, FREQ no ntp.drift
> *
> * FSET SYNC step, SYNC ntp.drift
> *
>
> NSET is the initial state for a cold start. FSET is the initial state
> for a warm start (ntp.drift) present. For a fast start you don't want
> NSET. Note that FSET goes to fully synchronised on one reading, but
> only steps the time if the offset is greater than the step limit, which
> normally 128ms.
>
> Furthermore, in the branch that is conditioned thus:
>
> if (fabs(fp_offset) > clock_max && clock_max > 0) {
>
> there is this comment:
>
> * In S_FSET state the initial frequency has been set
> * from the frequency file. Since the time is outside
> * the step threshold, the clock is stepped immediately,
> * rather than after the stepout interval. Guys get
> * nervous if it takes 17 minutes to set the clock for
> * the first time.
> *
>
> immediately followed by:
>
> step_systime(fp_offset);
>
> There is no step_systime in the else branch. clock_max is the tinkered
> value of the parameter that defaults to 128ms.
The above may mean something to YOU! Sorry but I don't see it!
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.org/mailman/listinfo/questions
