On Tue, May 12, 2015 at 11:33:31AM +0200, Marco Marongiu wrote:
On 12/05/15 11:28, Marco Marongiu wrote:
Hi there
In http://doc.ntp.org/4.2.6p5/ntpd.html#leap I read: If the leap is in
the future less than 28 days, the leap warning bits are set.
What are the practical consequences
On 13/05/15 13:23, Miroslav Lichvar wrote:
I'm not sure what exactly are you asking here. Do you see in your
testing or the source code something different from what is described
in the document?
No, I am trying to understand if what I understand* from the
documentation is correct.
* sorry
On 13/05/15 11:03, Miroslav Lichvar wrote:
On Tue, May 12, 2015 at 11:33:31AM +0200, Marco Marongiu wrote:
On 12/05/15 11:28, Marco Marongiu wrote:
Hi there
In http://doc.ntp.org/4.2.6p5/ntpd.html#leap I read: If the leap is in
the future less than 28 days, the leap warning bits are set.
On Wed, May 13, 2015 at 11:44:37AM +0200, Marco Marongiu wrote:
I understand that the leap second is not armed in the kernel if only the
warning is set. Rather, it seems that the warning is used by a client to
understand if it should believe its upstreams when they claim there will
be a leap
Hi,
I am seeing ntp not syncing to external configured servers. We tried both 4.2.4
and 4.2.6 versions.
The following is the configuration,
We use two servers 10.126.142.198 and 10.126.142.204 in our Lab.
They are statically configured as running @ stratum level 5 and providing the
clock from
Do your ntp servers have public IP addresses configured or do you do NAT for
the two ntp servers? 10.126.142.198 and 10.126.142.204 are private addresses
and won't be routed over the Internet.
The second place to check is firewall. Make sure it opens to upd/123 between
your ntp servers and
To expound upon Yu’s comment. If you don’t have access to the firewall, a good
check would be to conduct a test against each of your targeted NTP servers with
the “ntpdate -d” command, which is the debug switch and will let you know if
you can or cannot reach the intended systems.
-Dallas
Looks like both of the remote servers are beyond the recoverable step counter,
you’ll need to stop ntpd, then do an ntpdate -b $target_IP to recover them,
then restart the ntpd service.
-Dallas
On May 13, 2015, at 3:00 PM, Jochen Bern jochen.b...@linworks.de wrote:
On 05/13/2015 01:52
Your question is quite clear. As I stated, you want to ensure that you can, in
fact, access the targeted NTP servers via the debug switch in the ntpdate
command. If you’ve confirmed that access is not blocked by firewall and/or
ACL, then you’ll want to make sure you set the stratum correctly
Can you clarify if you’re setting “stratum 5” on your target servers, or your
local “fudge” server?
As far as I know, remote NTP servers should not require stratum option. I only
use this option on my local time source, and by that I mean issuing a rather
high value as to ensure that it’s
On 05/13/2015 01:52 PM, Chandrakanth K wrote:
bash-4.2$ ntpq -np -c assoc
remote refid st t when poll reach delay offset jitter
*127.127.1.0 .LOCL. 10 l 19 64 3770.000
11 matches
Mail list logo
