[ntp:questions] Re: Reach error codes

Richard B. Gilbert rgilbert88 at comcast.net
Mon Jan 23 22:53:16 UTC 2006


Nigel Henry wrote:

>On Monday 23 January 2006 21:36, Richard B. Gilbert wrote:
>  
>
>>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.
>>    
>>
>
>Hi Richard. Sounds like it's basically a dialup problem. I'll have to save up 
>for a GPS timing receiver as I'm on social security payments. Can you send 
>the URL for checking out the Garmin GPS18LVC, and the prices? Thanks for the 
>suggestions. Nigel.
>  
>
I don't have a URL handy for the Garmin but it has been mentioned 
recently on this list/newsgroup and I think a URL might have been included.




More information about the questions mailing list