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. On Tue, Jul 24, 2012 at 8:38 PM, unruh <un...@invalid.ca> wrote: > On 2012-07-24, bhargav p <bhargav.1...@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@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@lists.ntp.org > >> http://lists.ntp.org/listinfo/**questions< > http://lists.ntp.org/listinfo/questions> > >> > > > > > > > > _______________________________________________ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions > _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions