[ntp:questions] Request: Query on ntp step threshold value

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Wed May 17 21:07:33 UTC 2017


On 2017-05-15 12:23, Sowmya Manapragada wrote:
> Hello All,
> A request, have a query on how to verify modifications done to ntp step
> threshold value in ntp.conf:
> 
> ntp version: 4.2.8p9
> OS: windows 7 in a small lan, clients configured to sync with timesync ntp
> servers.

NTP servers can not be domain members as, if you are in a Windows domain,
you must use DC time. NTP servers can serve time to your DCs.

> *Modifications done* :
> *ntp.conf*
> # Specifies the step threshold in seconds. The default without this command
> is 0.128 s. If set to zero, step adjustments will never occur.# Note: The
> kernel time discipline is disabled if the step threshold is set to zero or
> greater than 0.5 s. Further details are on the
> #  Clock State Machine page (https://www.eecis.udel.edu/~m
> ills/ntp/html/clock.html).
> tinker step 0.128  => changed this to    ==>  tinker step 3
> 
> The snapshot of the logs are below , please correct me if my understanding
> is incorrect:
> 
> my changes:>
> ntp.conf:>> (enabled tinker step and stepout values)
> tinker step 3
> tinker stepout 300
> 
> ntp-logs:>
> 
> 10 Apr 22:08:05 ntpd[9828]: 0.0.0.0 0613 03 spike_detect +5.707447 s
> 10 Apr 22:25:34 ntpd[9828]: 0.0.0.0 061c 0c clock_step +5.739099 s
> 10 Apr 22:25:40 ntpd[9828]: 0.0.0.0 0615 05 clock_sync
> 10 Apr 22:25:41 ntpd[9828]: 0.0.0.0 c618 08 no_sys_peer

You need to get your server keeping time first, before tinkering.
If you are using an undisciplined local clock without good sources,
NTP is unlikely to work, it will continually step time.

> here since spike_detect is +5.70 >3 sec the clock will step  (expected).is
> this correct interpretation ?
> 
> If so, then how do we intrepret this log
> 10 Apr 21:40:28 ntpd[9828]: 0.0.0.0 0613 03 spike_detect -2.691201 s
> 10 Apr 21:42:42 ntpd[9828]: 0.0.0.0 061c 0c clock_step -2.679624 s
> 10 Apr 21:42:39 ntpd[9828]: 0.0.0.0 0615 05 clock_sync
> 10 Apr 21:42:40 ntpd[9828]: 0.0.0.0 c618 08 no_sys_peer
> 10 Apr 21:53:25 ntpd[9828]: 0.0.0.0 0628 08 no_sys_peer
> 
> here since spike_detect is -2.6 < 3 sec, so ideally clock_step should not
> happen (instead a slew is expected ? is correct analogy?
> i was going  by the definitions:
> 
> *>> spike_detect This is informational in that a difference between
> the local clock and the valid servers was temporarily greater than the
> 128ms max offset.
> *>* > clock_step Normally modifies the local system clock frequency to
> adjust for differences between it and the valid servers. If the offset
> is greater than 128ms (in our case 3 sec since we modified tinker step
> 3), then unless
> *>* > configured otherwise, will step the system clock.*

Before you tinker with any of these values, you need to read all the docs,
the RFCs, the Book, and understand the assumptions, engineering, and math
used. If you don't know the impact, and the other parameters you need to
adjust to keep the control loop stable, any changes are likely to make
operation unstable.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada


More information about the questions mailing list