[ntp:questions] Re: Reach error codes

Nigel Henry cave.dnb at tiscali.fr
Mon Jan 23 19:43:07 UTC 2006


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. 






>
> _______________________________________________
> questions mailing list
> questions at lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions



More information about the questions mailing list