[ntp:questions] Re: Reach error codes

Richard B. Gilbert rgilbert88 at comcast.net
Mon Jan 23 20:36:18 UTC 2006


Nigel Henry wrote:

>On Monday 23 January 2006 16:48, Richard B. Gilbert wrote:
>  
>
>>SivaKumar Subramani wrote:
>>    
>>
>>>When I execute the "ntpq -p" displays reach value for all the time
>>>source as 377.
>>>What it means? When this shall be set to proper value and system clock
>>>shall be sync'd.
>>>
>>>ntpq -p
>>>    remote           refid      st t when poll reach   delay
>>>offset    disp
>>>==========================================================================
>>>====
>>>
>>>143.209.133.66  143.209.150.72   3 u  696 1024  377   199.74  -725421
>>>15875.0
>>>143.209.150.72  131.107.1.10     2 u  691 1024  377   199.89  -726021
>>>15875.0
>>>143.209.150.232 143.209.150.72   3 u  707 1024  377   199.75  -723621
>>>15875.0
>>>
>>>What could be the problem?
>>>
>>>Thanks in advance.
>>>
>>>Thanks
>>>Sivakumar
>>>
>>>
>>>_______________________________________________
>>>questions mailing list
>>>questions at lists.ntp.isc.org
>>>https://lists.ntp.isc.org/mailman/listinfo/questions
>>>      
>>>
>>Start ntpd with the -g option.   This will cause it to set (step) the
>>clock on a one time basis.  This will get your clock within a few
>>milliseconds of the correct time before ntpd tries to synchronize it.
>>Without this option, ntpd can take hours or days to adjust your clock to
>>the correct time or, if your clock is off by more than 1024 seconds, it
>>will exit immediately (panic).
>>
>>The reach value of 377 is an octal number (representing 11111111 in
>>binary).   Each time a server responds to a poll, a 1 bit is shifted in
>>from the right hand side.  If a server fails to respond to a poll, a
>>zero bit is shifted in.   377 is a good value; it means that the server
>>responded to the last eight requests.   During startup, it should
>>successively display: 1, 3, 7, 17, 37, 77, 177 and 377.
>>    
>>
>
>Hi Richard. Thanks for the fine explanation as to how, "Reach" works. I still 
>have some problems with keeping the time synched on my 2 Linux machines. I 
>know that I am on dialup, and perhaps is not the best way to go using NTP. 
>The worst problem appears to be when I leave both machines running, and 
>connected to the Internet when I have to take a sleep. When the dialup 
>connection times out, the machine which retrieves time from the Internet has 
>problems. The system clock actually stops. The other machine, which retrieves 
>time across the LAN from this machine, has no problems, and retains the 
>correct time (as near as dammit). irrespective to how much the time has 
>slipped on the machine that retrieves time from the Internet. There is no 
>problem with the HWC on the machine connected to the Internet for time 
>retrieval, because, if I shut it down, and just leave the other machine 
>online, when I boot up this machine the following day the time is ok, and is 
>more or less in sync with the machine that has been running all night. The 
>problem strangely appears to be with the mouse. 
>
>As an example. Two machines. The one retrieving time from the machine 
>retrieving time from NTP servers on the Internet is as good as correct. The 
>other machine which is using the 3 time servers as below, has a clock which 
>has stopped (several hours before). I move the mouse pointer, and the clock 
>starts. Weird ! Now I reset the clock on this machine, using the reset time 
>and date facility. I leave this open. After a few minutes the clock stops 
>again, but moving the mouse pointer the clock then restarts. Very weird. The 
>mice I am using on both machines are, A4 Tech (Scrolltrack 4D) . Strangely 
>again. I. From time to time used to experience mouse pointer freeze-ups when 
>using Kmail, but since using NTP these have gone away. I know this is all a 
>bit weird, but has anybody else using these mice had problems like this?
>
>Putting all this stuff aside Richard, could you give me some info on the 
>"Jitter" header for ntpq?
>
>Out of interest, my last ntpq outputs. No lost dialup connections. One minute 
>one of the servers is acting as system peer, and then it's 
>gone.djmons at localhost djmons]$ /usr/sbin/ntpq
>ntpq> pe
>     remote           refid      st t when poll reach   delay   offset  jitter
>==============================================================================
> lptfpc46.obspm. 195.220.94.163   2 u  190  256   17  143.586    3.923  24.246
> ntp.kamino.fr   193.52.184.106   2 u  188  256   17  267.056   -6.443  18.756
> ntp2.belbone.be 195.13.23.250    2 u  191  256   17  139.354    2.339  14.114
>ntpq> pe
>     remote           refid      st t when poll reach   delay   offset  jitter
>==============================================================================
>+lptfpc46.obspm. 195.220.94.163   2 u   96  128  377  132.678   13.859  41.892
>+ntp.kamino.fr   193.52.184.106   2 u   30  128  377  265.910   -1.914  23.735
>*ntp2.belbone.be 195.13.23.250    2 u   97  128  377  139.210   -2.726  29.876
>ntpq> pe
>     remote           refid      st t when poll reach   delay   offset  jitter
>==============================================================================
> lptfpc46.obspm. 195.220.94.163   2 u    2  256  377  137.958    7.182 69016.1
> ntp.kamino.fr   193.52.184.106   2 u   52  256  377  269.283   -7.630 79694.6
>*ntp2.belbone.be 195.13.23.250    2 u  250  256  377  137.718   -1.639  11.855
>ntpq> pe
>     remote           refid      st t when poll reach   delay   offset  jitter
>==============================================================================
> lptfpc46.obspm. 195.220.94.163   2 u  259  256  377  137.958    7.182 69016.1
> ntp.kamino.fr   193.52.184.106   2 u   53  256  377  271.376  138027. 97601.0
> ntp2.belbone.be 195.13.23.250    2 u  247  256  377  137.718   -1.639 69014.4
>ntpq> pe
>     remote           refid      st t when poll reach   delay   offset  jitter
>==============================================================================
> lptfpc46.obspm. 195.220.94.163   2 u   44   64  377  133.507  232.575 9407.84
> ntp.kamino.fr   193.52.184.106   2 u   49   64  377  261.996  194.830 6663.51
> ntp2.belbone.be 195.13.23.250    2 u   44   64  377  141.394  182.646 9429.65
>ntpq> as
>ind assID status  conf reach auth condition  last_event cnt
>===========================================================
>  1 53836  b044   yes   yes  none    reject   reachable  4
>  2 53837  b044   yes   yes  none    reject   reachable  4
>  3 53838  b044   yes   yes  none    reject   reachable  4
>ntpq> pe
>     remote           refid      st t when poll reach   delay   offset  jitter
>==============================================================================
> lptfpc46.obspm. .STEP.          16 u  280   64    0    0.000    0.000 4000.00
> ntp.kamino.fr   .STEP.          16 u  212   64    0    0.000    0.000 4000.00
> ntp2.belbone.be .STEP.          16 u 1042   64    0    0.000    0.000 4000.00
>ntpq> pe
>     remote           refid      st t when poll reach   delay   offset  jitter
>==============================================================================
> lptfpc46.obspm. 195.220.94.163   2 u    5   64    3  137.987  17086.9  13.496
> ntp.kamino.fr   .STEP.          16 u  293   64    0    0.000    0.000 4000.00
> ntp2.belbone.be 195.13.23.250    2 u    5   64    3  191.824  17088.9  47.693
>ntpq> as
>ind assID status  conf reach auth condition  last_event cnt
>===========================================================
>  1 53836  b074   yes   yes  none    reject   reachable  7
>  2 53837  a064   yes   yes  none    reject   reachable  6
>  3 53838  b074   yes   yes  none    reject   reachable  7
>ntpq>
>
>I'm not having a go at anyone here. Perhaps it's just not possible to get 
>continuous good time using a dialup connection.
>
>Nigel. 
>
>  
>
Nigel,

Those ntpq -p billboards show me that your network connection is of 
wretched quality.  The delay figures show a round trip delay long enough 
to get a signal two thirds of the way around the earth at the equator!!  
I've got a broadband cable connection and I've never tried NTP over 
dialup.  The error in transmitting time from server to client is limited 
to one half the round trip delay which is why you want to keep your 
delay time low.

For a really good definition of "jitter" you'll have to consult a 
mathematician.  I can usually manage to count to twenty with my shoes on 
but "exponential averages" are meaningless noise to me.  My 
understanding, in English, is that jitter measures the random shifts in 
transmission delays which degrade the quality of the time received.  Low 
numbers are good.

If you really want to know what time it is, get a GPS timing receiver 
and use it as a hardware reference clock.   I have a Sun Ultra 10 using 
a Motorola Oncore M12+T receiver that synchronizes with errors in the 
tens of microseconds.   The clock is stable enough to enable the other 
machines in the house to synch to it within hundreds of microseconds.  
The Garmin GPS18 LVC is well thought of, low cost and, I believe, 
readily available. 




More information about the questions mailing list