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. > > _______________________________________________ > 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
