[ntp:hackers] ntpd 4.2.8p1 startup behaviour

Terje Mathisen terje at tmsw.no
Mon Feb 9 12:03:20 UTC 2015


Ronan Flood wrote:
> Hi folks.
>
> I've been test running ntpd 4.2.8p1 on our time-servers, and see
> a change in the startup behaviour from 4.2.6p5.  I'm not using
> iburst except with the refclocks, and therefore expect it to take
> a few minutes to gather enough samples from network peers to run
> the core algorithms, but sync to the refclock in the meantime.
>
> With 4.2.8p1, ntpd can react immediately to the first response
> from a server and declare itself synchronised, eg:
>
>   Feb  5 14:57:09 ntp1.ja.net ntpd-4.2.8p1[4404]: [ID 702911 local6.info] 0.0.0.0 c016 06 restart
>
>   Feb  5 14:57:10 ntp1.ja.net ntpd-4.2.8p1[4404]: [ID 702911 local6.info] 195.66.241.10 8024 84 reachable
>   Feb  5 14:57:10 ntp1.ja.net ntpd-4.2.8p1[4404]: [ID 702911 local6.info] 195.66.241.10 903a 8a sys_peer
>   Feb  5 14:57:10 ntp1.ja.net ntpd-4.2.8p1[4404]: [ID 702911 local6.info] 0.0.0.0 c615 05 clock_sync
>   
>   Feb  5 14:57:10 ntp1.ja.net ntpd-4.2.8p1[4404]: [ID 702911 local6.info] GPS_PALISADE(0) 8024 84 reachable
>
>   Feb  5 14:57:26 ntp1.ja.net ntpd-4.2.8p1[4404]: [ID 702911 local6.info] GPS_PALISADE(0) 903a 8a sys_peer
>
>
> I'm concerned that by not gathering samples, it might select a bad
> initial server -- I don't want our time-servers stepping to a
> false-ticker!
>
> I've not spotted what has changed in the code to alter the behaviour
> from needing reach 17 or whatever, and I don't know if this was
> intentional, hence asking here rather than raising a bug.
>
>
It is the local refclock (GPS_PALISADE) which is becoming reachable and 
then selected, this makes sense since a GPS can be polled every second, 
so after 17 samples (over 16 seconds) it has enough samples to start 
trusting it. Do you have a 'prefer' as well on that refclock?

Terje

-- 
- <Terje at tmsw.no>
"almost all programming can be viewed as an exercise in caching"



More information about the hackers mailing list