[ntp:questions] Re: Reach error codes

Nigel Henry cave.dnb at tiscali.fr
Tue Jan 24 19:20:56 UTC 2006


On Monday 23 January 2006 23:53, Richard B. Gilbert wrote:
> 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.

Hi Richard. A little update. On both FC2 machines I was using 
kernel-2.6.10-0.4.rdt.rhfc2.ccrma with the module rtload loaded. rtload was 
loading last, but was causing problems as it loaded after ntpd. Fernando, at 
planetccrma suggested moving the load point to before ntpd, which I did, and 
then didn't have problems with ntpd after login to KDE. Previously after 
logging in to KDE, and with rtload loading last, ntpd was shown with ps auxw 
as being dead. Last night I booted the machine using Internet time servers 
with the original Fedora kernel (2.6.5-1.358) , and have had no time-slips. I 
admit that during the night I lost the power, but this had been running 
sufficient time to show the usual time-slips. I am posting the latest ntpq> 
pe & as billboards. The first shows ntp.kamino.fr with a very short delay, 
and even though it has no leading * ntpq> as shows it to be a system peer. 
The second billboard shows longer delays. What sort of delays should I be 
seeing if ntp is working as it should?

Incidentally the other machine which has FC2 running on it at the moment, and 
is using the planetccrma 2.6.10-0.4 kernel, and with rtload, and is 
retrieving time from the other machine which is retrieving time from the 
Internet, is showing as it allways does, no time-slips, even when the dial-up 
connection is down.

I appreciate that different set-ups could interfere with the way that ntp is 
supposed to work. Can anyone help to explain why using the planetccrma kernel 
with rtirq & rtload, then losing a dialup connection, results in severe 
time-slips, but when using the vanilla kernel with no realtime support, the 
time remains stable. I've been running FC2 all day with the vanilla kernel, 
and with no time-slips, irrespective of delay times. 

Latest ntpq> pe & as below:

    remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 lptfpc46.obspm. 195.220.94.163   2 u  172  256   17  140.218    5.254   9.388
 ntp.kamino.fr   193.52.184.106   2 u  241  256   17    0.002  -251.08 240.560
 ntp2.belbone.be 195.13.23.250    2 u  170  256   17  142.250   -1.089   8.770
ntpq> as
ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 12988  b024   yes   yes  none    reject   reachable  2
  2 12989  b624   yes   yes  none  sys.peer   reachable  2
  3 12990  b024   yes   yes  none    reject   reachable  2
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*lptfpc46.obspm. 195.220.94.163   2 u   53   64  377  132.057    1.652   9.963
+ntp.kamino.fr   193.52.184.106   2 u   59   64  377  270.752   -7.146  10.464
+ntp2.belbone.be 195.13.23.250    2 u   55   64  377  140.738   -5.597  11.686
ntpq> as
ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 12988  b624   yes   yes  none  sys.peer   reachable  2
  2 12989  b424   yes   yes  none  candidat   reachable  2
  3 12990  b424   yes   yes  none  candidat   reachable  2
ntpq>

Thanks for all the help. 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