[ntp:questions] Facing some issue in the ntp version Ver. 4.2.6p1

David Woolley david at ex.djwhome.demon.invalid
Mon Jul 23 20:41:55 UTC 2012


bhargav p wrote:

> 
> Coming to actual problem in my scenario, In my conf file i have configured
> one server address and local[127.127.1.0] address. As for each peer we are

Why have you done this?  First of all, leaf nodes should never have the 
local clock pseudo driver defined.  Secondly, with modern versions of 
ntpd, the only real reason to use one on a non-leaf noed is if you are 
using a timing source outside of ntpd, in which case the local clock 
driver will be the only server defined.

When you want the whole network to coast together, you should use orphan 
mode.

If you must use the local clock as a fallback, I would advise defining 
enough real servers to safely outvote it, and setting the clock to 
within a second or so, before starting ntpd.

> setting that flag , when I changed the date and trying to set it " ntpd -q
> " command , when the first NTP packet is received, for the local address
> hash iteration this condition[(!(peer->flags & FLAG_REFCLOCK] is failing
> and returning as fit and trying to synchronize with local server and
> printing the log "slew +0.0000000sec".. and all NTP packet exchange is
> stopped after first pair exchange.

Yes, that's the sort of problem you get from inappropriate use of that 
driver.

> 
> 
> If I remove this check [(!(peer->flags & FLAG_REFCLOCK] in peer_unfit
> function, then everything is fine.Time has been reset to the server value.

It sounds to me that you have effectively removed the local clock 
entirely.  The local clock needs to be treated as a refclock, so that 
time served remains valid indefinitely.  On modern ntpd's, even without 
orphan mode or local clock drivers, a non-leaf node will continue to 
serve time long after its sources have gone away.  However the root 
distance will increase until its clients decide it is too great.
> 
> I am not sure why this flag check is required?
> 



More information about the questions mailing list