[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