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