David Woolley da...@ex.djwhome.demon.co.uk.invalid 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
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
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 than
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
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 disciplined local clock
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
Ronaldo Mexico ronaldo.hawk.mex...@gmail.com 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
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 refid
Ronaldo Mexico ronaldo.hawk.mex...@gmail.com 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 use...@umbral.org.uk
___
questions mailing list
David Woolley da...@ex.djwhome.demon.co.uk.invalid 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
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 loop.
Nope, the
Ronaldo Mexico ronaldo.hawk.mex...@gmail.com 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
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:
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 jitter
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
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
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
On 2009-06-25, Ronaldo Mexico ronaldo.hawk.mex...@gmail.com 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),
On Thu, Jun 25, 2009 at 10:17:52AM -0700, Ronaldo Mexico wrote:
On Jun 25, 12:36 pm, Steve Kostecke koste...@ntp.org wrote:
On 2009-06-25, Ronaldo Mexico ronaldo.hawk.mex...@gmail.com wrote:
ntpq rv 62340
assID=62340 status=9014 reach, conf, 1 event, event_reach,
srcadr=ntp,
On Jun 25, 10:57 am, Ronaldo Mexico ronaldo.hawk.mex...@gmail.com
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
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 blackl...@anitech-systems.com
will be added to the BlackLists.
On 2009-06-25, Ronaldo Mexico ronaldo.hawk.mex...@gmail.com wrote:
On Jun 25, 12:36 pm, Steve Kostecke koste...@ntp.org wrote:
On 2009-06-25, Ronaldo Mexico ronaldo.hawk.mex...@gmail.com wrote:
ntpq rv 62340 assID=62340 status=9014 reach, conf, 1 event,
event_reach, srcadr=ntp,
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
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
In article
d8384c7d-f151-4405-86b6-d6a96e656...@j19g2000vbp.googlegroups.com,
Ronaldo Mexico ronaldo.hawk.mex...@gmail.com 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
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
26 matches
Mail list logo
