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.
