Re: ntpq no longer working -

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ed Greshko wrote:
Bob Goodwin wrote:
Ed Greshko wrote:
Bob Goodwin wrote:
taharka wrote:
How do,

On Mon, 2006-05-22 at 07:32 -0400, Bob Goodwin wrote:
Tim wrote:
On Mon, 2006-05-22 at 04:17 -0400, Bob Goodwin wrote:
server
clock2.redhat.com server ntp-1.cns.vt.edu server ntp-2.cns.vt.edu server ntp-3.cns.vt.edu server ntp-4.cns.vt.edu
Cut and paste error?  They should all look more like:

server
clock2.redhat.com server ntp-1.cns.vt.edu server ntp-2.cns.vt.edu server ntp-3.cns.vt.edu server ntp-4.cns.vt.edu
Yes, that is exactly what it looks like before Mozilla Compose
mutilated them
in producing "plain text."
Those domains all resolve, here.  But I don't think you're doing
yourself any favours by referring to a bunch of NTP servers at the
same
location.  You want a collection of different servers, else you might
believe a set of servers to be true, that believe themselves to
all be
true, when they're not (they might all be referencing themselves).
Originally I had three different sources within a few hundred miles in
hope of minimizing delays, some went away over time and the two left
always
worked well enough for my purposes.  Your suggestion is obviously
valid. But I still can't see what's happening, since ntpq doesn't
work even when I
reduce the list to just the Redhat server.
I picked a collection that come from different locations:

server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburst

Plus a couple of more local ones, to me (au.pool.ntp.org and my
ISP's)
I can do something similar but first need to fix my problem.
Any hints/errors in /var/log/ntp?
I haven't found any such log, locate *log*ntp* produces nothing I
recognize as useful?

I did find:  /usr/bin/ntpstat
synchronised to NTP server (198.82.1.203) at stratum 3
  time correct to within 79 ms
  polling server every 512 s

Which seems to indicate ntp is working at least but I don't have the
convenient data display I am accustomed to.
Why not try using ntpq in interactive mode.  Use -i to get to that
state.  Then raise the debug level with "debug more" and try "peers".

Ed
This is what I got ;

ntpq -i
Name or service not known
ntpq> debug more
debug level set to 1
ntpq> peers
***No host open, use `host' command
ntpq> host 198.82.1.203
current host set to 198.82.1.203
ntpq> peers
198.82.1.203: timed out, nothing received
***Request timed out
ntpq> debug more
debug level set to 2
ntpq> peers
198.82.1.203: timed out, nothing received
***Request timed out
ntpq>

I'm not sure I'm using this right but it seems not matter what I try
ntpq does nothing
and it always worked in the past.  At first I thought it might be due to
the round trip transit time
between here and the satellite which probably add a quarter of a
second?  But it seems to me that
I've seen some long delays in the ntpq data at times although that's not
typical, normally more like
.160 [s/ms?].

I assume ntpd is running....

Anyway, instead of setting host to 198.82.1.203 set it to 127.0.0.1 and
try again.
Ok, that produces some meaningful data, I don't know how Mozilla Compose will mangle it but :

ntpq> host 127.0.0.1
current host set to 127.0.0.1
ntpq> peers
Got packet, size = 32
Packet okay
***Can't find host localhost
remote refid st t when poll reach delay offset jitter
==============================================================================
Got packet, size = 432
Packet okay
Got packet, size = 220
Packet okay
clock2.redhat.c .CDMA. 1 u 110 1024 377 2030.40 633.536 558.706
Got packet, size = 444
Packet okay
Got packet, size = 220
Packet okay
ntp-1.cns.vt.ed 198.82.247.40 2 u 410 1024 377 2568.57 901.177 706.564
Got packet, size = 440
Packet okay
Got packet, size = 212
Packet okay
*ntp-2.cns.vt.ed 198.82.247.40 2 u 397 1024 377 769.755 -22.853 76.805
Got packet, size = 444
Packet okay
Got packet, size = 212
Packet okay
ntp-3.cns.vt.ed 198.82.247.40 2 u 581 1024 377 1694.40 427.961 328.748
Got packet, size = 440
Packet okay
Got packet, size = 212
Packet okay
+ntp-4.cns.vt.ed 198.82.247.40 2 u 85 1024 377 873.344 46.931 109.827

The delay and offset numbers look pretty high, perhaps system delays via the satelltie connection?

BobG

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux