[ntp:questions] Facing some issue in the ntp version Ver. 4.2.6p1
unruh
unruh at invalid.ca
Tue Jul 24 18:47:05 UTC 2012
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
>>
More information about the questions
mailing list