[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