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
[email protected]
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
[EMAIL PROTECTED] 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.
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
