ntpq no longer working -

Bob Goodwin bobgoodwin at wildblue.net
Mon May 22 15:39:45 UTC 2006


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




More information about the fedora-list mailing list