[ntp:questions] Re: Reach error codes

Nigel Henry cave.dnb at tiscali.fr
Mon Jan 23 22:16:15 UTC 2006


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.
>
> _______________________________________________
> questions mailing list
> questions at lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions



More information about the questions mailing list