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 <[email protected]> wrote: > On 2012-07-26, bhargav p <[email protected]> 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 <[email protected]> wrote: > > > >> On 2012-07-24, bhargav p <[email protected]> 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 <[email protected]> wrote: > >> > > >> >> On 2012-07-24, bhargav p <[email protected]> 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 < > >> >> > [email protected]> 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 > >> >> >> [email protected] > >> >> >> http://lists.ntp.org/listinfo/**questions< > >> >> http://lists.ntp.org/listinfo/questions> > >> >> >> > >> >> > > >> >> > > >> >> > > >> >> > >> >> _______________________________________________ > >> >> questions mailing list > >> >> [email protected] > >> >> http://lists.ntp.org/listinfo/questions > >> >> > >> > >> _______________________________________________ > >> questions mailing list > >> [email protected] > >> http://lists.ntp.org/listinfo/questions > >> > > _______________________________________________ > questions mailing list > [email protected] > http://lists.ntp.org/listinfo/questions > _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
