David Woolley wrote:
> > Yes, and fudge the stratum to 1, not 2.
>
> You mean zero, not 1,
You're right, 0, so that the server is seen as stratum 1 by the client.
> which might be the problem, i.e. either fudge
> doesn't allow that, or the people who bolted NTP onto the time server
> thought
Ronan Flood wrote:
>
> Yes, and fudge the stratum to 1, not 2.
>
You mean zero, not 1, which might be the problem, i.e. either fudge
doesn't allow that, or the people who bolted NTP onto the time server
thought it didn't
___
questions mailing list
Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
> David Woolley wrote:
>
> >> The question remains why the Brandywine PTS device is claiming synch
> >> to LOCAL(O) with stratum 2.
> >>
> > I suspect it is using the local clock driver for its original purpose,
> > i.e. to propagate the value o
Terje Mathisen wrote:
> David Woolley wrote:
>> Ronan Flood wrote:
>>
>>>
>>> The question remains why the Brandywine PTS device is claiming synch
>>> to LOCAL(O) with stratum 2.
>>>
>> I suspect it is using the local clock driver for its original purpose,
>> i.e. to propagate the value of a discip
David Woolley wrote:
> Ronan Flood wrote:
>
>>
>> The question remains why the Brandywine PTS device is claiming synch
>> to LOCAL(O) with stratum 2.
>>
> I suspect it is using the local clock driver for its original purpose,
> i.e. to propagate the value of a disciplined local clock that is
> d
On Fri, Jun 26, 2009 at 11:34:11AM +, Ronan Flood wrote:
> The question remains why the Brandywine PTS device is claiming synch
> to LOCAL(O) with stratum 2.
Maybe the NTP implementation is just replying with the client's refid,
which is INIT first and then LOCAL(0).
--
Miroslav Lichvar
Ronan Flood wrote:
>
> The question remains why the Brandywine PTS device is claiming synch
> to LOCAL(O) with stratum 2.
>
I suspect it is using the local clock driver for its original purpose,
i.e. to propagate the value of a disciplined local clock that is
disciplined by something other tha
Dave,
The reported configuration is as bad as it gets and is exactly what
orphan mode was designed to avoid.
For record ans as described on the Mitigation Algorithms and the Prefer
Peer page, a loop is detected if he is synchronized to me or if he and I
are syncronized to the same IP address.
Ronaldo Mexico wrote:
> Steps were taken (fudge 10) to make sure the local clock is only
> chosen in the worst-case scenario. Even if I remove the local clock
> (127.127.1.0), it'll still never sync to the only choice it has (the
> PTS).
Are you sure about that? If it doesn't work without the
Correcting myself :-/
I wrote:
> In 4.2.2 this is adjusted to
>
> (peer->stratum > 1 && peer->refid != htonl(LOOPBACKADR) &&
>(peer->refid == peer->dstadr->addr_refid || peer->refid == sys_refid))
>
> which implies that the OP's RHEL server is running 4.2.0 as it sees
> 127.0.0.1 as a loo
David Woolley wrote:
> Harlan Stenn wrote:
>
> > If you are using LOCAL as a fallback on your client, and your upstream
> > server is using LOCAL ias the name for its PTS-sync'd refid, then the client
> > just sees that the 2 sources it knows about are using the same refid and
> > will flag that
Ronaldo Mexico wrote:
> Unfortunately, it's the RHEL server (147.159.120.206). The PTS is on
> 147.159.120.131.
Can you do "ntpq -np 147.159.120.131" ?
--
Ronan Flood
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman
On Fri, Jun 26, 2009 at 7:04 AM, David Woolley wrote:
> Harlan Stenn wrote:
>
>> If you are using LOCAL as a fallback on your client, and your upstream
>> server is using LOCAL ias the name for its PTS-sync'd refid, then the client
>> just sees that the 2 sources it knows about are using the same r
Ronaldo Mexico wrote:
> In reply to Gene Miller and Steve Kostecke:
>
>> If the PTS is connected to a reference clock, why does it report
>> itself as a stratum 2 with a refid of either 73.78.73.84 or LOCAL(0),
>> as shown in the original posting:
>
> The PTS -is- it's reference. It's time is bas
Harlan Stenn wrote:
> If you are using LOCAL as a fallback on your client, and your upstream
> server is using LOCAL ias the name for its PTS-sync'd refid, then the client
> just sees that the 2 sources it knows about are using the same refid and
> will flag that as a loop.
>
That doesn't sound s
>>> In article
>>> ,
>>> Ronaldo Mexico writes:
Ronaldo> In reply to Gene Miller and Steve Kostecke:
>> If the PTS is connected to a reference clock, why does it report itself
>> as a stratum 2 with a refid of either 73.78.73.84 or LOCAL(0), as shown
>> in the original posting:
Ronaldo> The PT
In reply to Gene Miller and Steve Kostecke:
> If the PTS is connected to a reference clock, why does it report
> itself as a stratum 2 with a refid of either 73.78.73.84 or LOCAL(0),
> as shown in the original posting:
The PTS -is- it's reference. It's time is based on GPS-fed data, then
interna
Ronaldo Mexico wrote:
>
> Unfortunately, it's the RHEL server (147.159.120.206). The PTS is on
> 147.159.120.131. There are no other NTP servers in the private
> network.
This is why configuring a local clock driver is dangerous. Especially as
you are mixing in w32time, that won't understand
On 2009-06-25, Ronaldo Mexico wrote:
> On Jun 25, 12:36 pm, Steve Kostecke wrote:
>
>> On 2009-06-25, Ronaldo Mexico wrote:
>>
>> > ntpq> rv 62340 assID=62340 status=9014 reach, conf, 1 event,
>> > event_reach, srcadr=ntp, srcport=123, dstadr=147.159.120.206,
>> > dstport=123, leap=00, stratum=
Gene Miller wrote:
> If the PTS is connected to a reference clock, why does it report
> itself as a stratum 2 with a refid of either 73.78.73.84 or LOCAL(0),
73.78.73.84 = INIT
--
E-Mail Sent to this address
will be added to the BlackLists.
___
que
On Jun 25, 10:57 am, Ronaldo Mexico
wrote:
> In the system I'm configuring, we have a real time source (the PTS,
> sync'd via GPS to an authentic time source) and for the extreme backup
> case (physical failure), the local clock.
If the PTS is connected to a reference clock, why does it report
i
On Thu, Jun 25, 2009 at 10:17:52AM -0700, Ronaldo Mexico wrote:
> On Jun 25, 12:36 pm, Steve Kostecke wrote:
> > On 2009-06-25, Ronaldo Mexico wrote:
> >
> > > ntpq> rv 62340
> > > assID=62340 status=9014 reach, conf, 1 event, event_reach,
> > > srcadr=ntp, srcport=123, dstadr=147.159.120.206, ds
On Jun 25, 12:36 pm, Steve Kostecke wrote:
> On 2009-06-25, Ronaldo Mexico wrote:
>
> > ntpq> rv 62340
> > assID=62340 status=9014 reach, conf, 1 event, event_reach,
> > srcadr=ntp, srcport=123, dstadr=147.159.120.206, dstport=123, leap=00,
> > stratum=2, precision=-20, rootdelay=0.000, rootdispe
On 2009-06-25, Ronaldo Mexico wrote:
> ntpq> rv 62340
> assID=62340 status=9014 reach, conf, 1 event, event_reach,
> srcadr=ntp, srcport=123, dstadr=147.159.120.206, dstport=123, leap=00,
> stratum=2, precision=-20, rootdelay=0.000, rootdispersion=0.000,
> refid=LOCAL(0), reach=377, unreach=0, hm
Ronaldo Mexico wrote:
[]
> Hmm, that's a good question. I'm using Windows XP and set the ntp
> server based on the Date and Time Properties --> Internet Time. I
> have no idea if it's being governed by the w32time service.
Ronaldo,
With some versions of Windows, w32time doesn't play well with o
Replies to David Woolley:
> This is pretty much a worst case configuration. Drop the local clock,
> or add enough real servers to outvote it. However, I don't think that
> would produce a reject status. There is an aberration in most ntpd
> based packages that they contain a local clock pseudo
In reply to (BlackLists man):
> I don't see a NTP server on 147.159.120.131
> is it restricted to local access?
I'm not sure what that question means. It's on the same subnet, but
you may be referring to the restricted keyword in the ntp.conf file?
>
> What happens if you add to your ntp.conf
>
Ronaldo Mexico wrote:
> For some reason, the ntpd daemon on RHEL refuses to sync with the
Red Hat use the Reference implementation, at least as far as the core
code is concerned.
> [r...@screamer-dc1 init.d]# ntpq -p
> remote refid st t when poll reach delay
> offset jitt
Ronaldo Mexico wrote:
> I've tried various searches using google and hear in the
> group to see if someone has run into something similar,
> but the only people who have questions similar to mine
> never got answered, so I'm hoping bringing it up again
> with a bit more detail will help get it
I've tried various searches using google and hear in the group to see
if someone has run into something similar, but the only people who
have questions similar to mine never got answered, so I'm hoping
bringing it up again with a bit more detail will help get it solved.
We have physical NTP server
30 matches
Mail list logo
