On Sun, 2006-10-22 at 11:46 -0700, Wolfgang S. Rupprecht wrote: > "Rob Brown-Bayliss" <uncertain.genius@xxxxxxxxx> writes: > > [root@localhost ~]# ntpq -p > > remote refid st t when poll reach delay offset jitter > > ============================================================================== > > mu-relay1.masse 192.5.41.40 2 u 16 64 177 170.570 -798.72 12760.3 > > ns1.compass.net 128.250.36.3 2 u 14 64 177 112.739 -13008. 7668.06 > > cobol.appello.n 128.250.37.2 2 u 14 64 177 162.234 -897.55 11922.0 > > ntp.thistledown .GPS. 1 u 19 64 177 203.800 -3927.4 9253.24 > > gen2.ihug.co.nz 130.217.76.49 2 u 14 64 177 140.795 -7057.9 7349.37 > > Actually that looks good as far as ntpd synch-ing to outside servers > goes. The servers it is syncing to, or the network connection it is > syncing over, on the other hand suck big-time. Notice the "offset" > fields all differ from one another by a very large number of > milliseconds. I see an offset of 0.7 0.8 3.9 7 13 seconds! No 3 > servers seem to agree as to what time it really is. Thats not good at > all. If your network connection is really overloaded (with up to a 13 > second delay in a packet), then ntp is going to have a very hard time > setting the time on your system. > > The "reach" is really a bitfield that shifts ones from lsb to msb so > it should indicate how many of the last 8 packets it successfully got > back. When ntpd starts expect that number to count as such: 1, 3, 7, > 17, 37, 77, 177, 377. > > The next thing to watch for is the first column in the ntpq -p output. > Eventually some +'s -'s and *'s will appear. These are servers that > ntp has synced with or are potential candidates. If it is doing that, > then all is ok. > > > [root@localhost ~]# ntpdate > > 23 Oct 06:15:35 ntpdate[3869]: no servers can be used, exiting > > ntpdate when run from the command line needs the servers listed by > hand. I don't know why it doesn't grab them from ntpd.conf as a > default, but it doesn't. Just grab one or all the servers / peers > listed in your /etc/ntp.conf file. > One of us must be a little confused here. /etc/init.d/ntpd (which starts ntpd for you at startup) explicitly calls nptdate prior to starting ntpd. It first tries to use the step tickers listed in /etc/ntp/step-tickers. If it cannot use them then it falls back to use the servers listed in /etc/ntp.conf. On my system that means it does use ntp.conf since step-tickers is empty and always has been. True, if you run ntpdate manually from the command line you need to provide the server for it to connect to. How many of us really want to do it that way? > You won't be able to run ntpdate without the -d flag unless you stop > ntpd. I wouldn't stop it. I'd just let it run for a day and try to > get synced up. The first time you run ntpd it will take a while as it > is tuning the ntp.drift file for you. It may take 2-3 days for the > drift file to be adjusted. > If ntpd sees the time as too far off it will refuse to continue trying and that is not a good thing IMHO. The easiest way I have found is to simply do a service ntpd stop followed by a service ntpd start which takes care of running ntpdate to get any existing major time discrepancies adjusted, then runs ntpd to fine tune it and keep it accurate. > -wolfgang > -- > Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/ >
