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

bhargav p bhargav.1226 at gmail.com
Thu Jul 26 17:42:32 UTC 2012


Hi,

>>>>And we keep telling you to get rid of the "local" server. And you keep
>>>>ignoring the advice and plowing on
>>>>If I get rid of local server for me it is working fine.

If i remove the local server it is working fine.

Thanks all for the help.

-Bhargav
On Thu, Jul 26, 2012 at 7:47 PM, unruh <unruh at invalid.ca> wrote:

> On 2012-07-26, bhargav p <bhargav.1226 at gmail.com> wrote:
> > 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..
>
> ??? What do you mean they are nodes on one machine? So you mean that
> BCDE are virutal machines? Why do they not simply get their time from A,
> not via ntp but just reading thetime?
>
> >
> > 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.
>
> And we keep telling you to get rid of the "local" server. And you keep
> ignoring the advice and plowing on.
>
> Note that "change the date manually" is NOT the way to test ntpd.
>
>
>
>
> >
> > 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.?
>
> It is NOT required. It is sometimes used as a legacy but better options
> now exist (eg orphan mode).
> If you want to submit a bug report please do so, but do not expect it to
> be acted on.
>  >
> > 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
> >>
>
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions
>


More information about the questions mailing list