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

bhargav p bhargav.1226 at gmail.com
Thu Jul 26 11:47:08 UTC 2012


Hi All,

Please find my scenario:

I have one machinewhich will have multiple blades[nodes] as below:


 A

 B

 C

 D

 E

Let say A,B,C,D,E are nodes in one machine..

I have configuration such a way that A will contact to the external server
for time synchronization and B,C,D,E will contact to A for time.

So on A's configuration I have one server and local address configured in
my conf file.

If I change the date manually on A, and try to synchronize with server, it
is not happening with the log message "time slew +0.00000sec". As I
explained earlier this is because of the check (!peer->flags &
FLAG_REFCLOCK &&,distance check>)..Local clock is treated as fit and tried
to synchronize with local clock so logging the above error. And ntpq -pn
shows * mark on the external peer configuration.

Note in ntpd code for Local address peer, FLAG_REFCLOCK is set and then
inserted into hash table.

So if any local lock is configured is configured in our conf file
FLAG_REFCLOCK is set fo that and inserted in hash table.

After changing the date, If I execute ntpd -q option to set the time
immediately [this is how I want].

Now the problem starts, when first NTP packet received, the clock_select()
funtion is called. In clock_select we are iterating through the hash tree
for all the peers stored in the hash , so when the local address iteration
came, peer_unfit() functon is called for local clock and this (!peer->flags
& FLAG_REFCLOCK  && <distance check> ) donot hit and treating local hit as
fit and trying to synch with that , as there is no much time diff with
local clock it is throwing with the log "time slw +0.00000sec".

If I remove that flag check, and only root_distance is calculated and
ttreat it as unfit, and when the externl peer's root distance is less than
the threshold then my clock is synchronizing to the peer.

So the question is

Is this flag check is required in my case? Because in my
configuration local clock is required as my node A in non-leaf node.?

Can anyone please  clarify regarding this issue.


-Bhargav


On Wed, Jul 25, 2012 at 12:17 AM, unruh <unruh at invalid.ca> wrote:

> On 2012-07-24, bhargav p <bhargav.1226 at gmail.com> wrote:
> > My machine is the server for other nodes[blades] in the cluster.So it is
> > not a leaf machine.
> >
> > The main issue is that, if local clock is there there is an issue with
> the
> > flag check in the peer_unfit ()..If the flag check is not there then even
> > if local configuration is there everything is fine.
>
> But local should not be there. And you should be using more than one
> extra server.
> The ONLY reason local should be there is that your machine acts as a
> server and it MUST always be there claiming to be synchronized, and you
> cannot use orphan mode.
> Ie, never.
>
> >
> > On Tue, Jul 24, 2012 at 8:38 PM, unruh <unruh at invalid.ca> wrote:
> >
> >> On 2012-07-24, bhargav p <bhargav.1226 at gmail.com> wrote:
> >> > Hi,
> >> >
> >> > Thanks for reply.
> >> >
> >> > I am confused with what is a leaf node and non-leaf node.
> >>
> >> A leaf sits at the end of a branch. I presume it is a node on which
> >> nothing else depends. Ie, no other machine uses it as a server.
> >>
> >>
> >> >
> >> >>>>>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 have not removed local clock. I just removed the check, still my
> local
> >> > address configuration is preset in my conf file.
> >> >
> >>
> >> And why have you not removed the local clock. It is idiotic to use it as
> >> a refclock, especially if your computer is not being used as a server by
> >> a whole bunch of other machines. It does nothing but confuse everything.
> >> Remove it!
> >>
> >> > In why earlier versions of ntpd this flag check is not there?
> >> >
> >> >
> >> >
> >> >
> >> > On Tue, Jul 24, 2012 at 2:11 AM, David Woolley <
> >> > david at ex.djwhome.demon.invalid> wrote:
> >> >
> >> >> 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?
> >> >>>
> >> >>>
> >> >>  ______________________________**_________________
> >> >> questions mailing list
> >> >> questions at lists.ntp.org
> >> >> http://lists.ntp.org/listinfo/**questions<
> >> http://lists.ntp.org/listinfo/questions>
> >>  >>
> >> >
> >> >
> >> >
> >>
> >> _______________________________________________
> >> questions mailing list
> >> questions at lists.ntp.org
> >> http://lists.ntp.org/listinfo/questions
> >>
>
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions
>


More information about the questions mailing list