From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1FBzXO-0008C5-I5 for garchives@archives.gentoo.org; Wed, 22 Feb 2006 19:20:34 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k1MJJWjC009720; Wed, 22 Feb 2006 19:19:32 GMT Received: from mailbox7.ucsd.edu (mailbox7.ucsd.edu [132.239.1.59]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id k1MJF0r6023952 for ; Wed, 22 Feb 2006 19:15:01 GMT Received: from smtp.ucsd.edu (smtp.ucsd.edu [132.239.1.49]) by mailbox7.ucsd.edu (8.13.5/8.13.5) with ESMTP id k1MJEZTS043844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 22 Feb 2006 11:14:35 -0800 (PST) Received: from umbra (umbra.ucsd.edu [132.239.1.85]) by smtp.ucsd.edu (8.13.5/8.13.4) with ESMTP id k1MJEYMR098238 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 22 Feb 2006 11:14:35 -0800 (PST) From: "Brandon Enright" To: Subject: RE: [gentoo-user] NTP problem Date: Wed, 22 Feb 2006 19:13:22 -0000 Message-ID: <009501c637e4$0c64ed90$5501ef84@umbra> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <43FCAFA9.8080108@gt.rr.com> Thread-Index: AcY332UYmtWcdIaETruAOGToTE1vNgAArKRQ X-Greylisting: NO DELAY (Trusted relay host); processed by UCSD_GL-v2.1 on mailbox7.ucsd.edu; Wed, 22 February 2006 11:14:35 -0800 (PST) X-MailScanner: PASSED (v1.2.8 25097 k1MJEZTS043844 mailbox7.ucsd.edu) X-Archives-Salt: bc71dc3f-3e63-4f1b-b7b8-a204880c101b X-Archives-Hash: f84fd117020fe1d180566ab6344a85db Anthony E. Caudel wrote: > Brandon Enright wrote: > > > > > So from your output a couple issues stick out. You're only peering with > > one machine which generally doesn't work so well. You're probably > > better off just using ntpdate periodically if you are only going to > > sample one server. > > > > Also, the delay on the server you are polling is over 200 ms. I'm not > > sure where ntp3.usv.ro is located but it is over 260ms for me too. With > > this high network delay, slight network jitter can make your clock think > > it is way off. Your machine thinks it is 7.3 ms off. If you had more > > servers to peer with and *much* lower average delay between those > > servers your clock would stabilize. As it stands now, you clock > > probably won't ever stabilize because your network is the primary source > > of uncertainty. > > > > For comparison, here is my ntpq -c rv output: > > > > assID=0 status=06f4 leap_none, sync_ntp, 15 events, > > event_peer/strat_chg, > > version="ntpd 4.2.0a@1.1190-r Mon Oct 17 21:31:52 PDT 2005 (1)"?, > > processor="i686", system="Linux/2.6.10-gentoo-r6", leap=00, stratum=2, > > precision=-20, rootdelay=21.642, rootdispersion=41.662, peer=12542, > > refid=132.249.20.88, > > reftime=c7a70d4a.975935fc Wed, Feb 22 2006 16:18:18.591, poll=10, > > clock=0xc7a70dc0.a5847f56, state=4, offset=-0.007, frequency=-31.438, > > noise=1.052, jitter=2.529, stability=3.132 > > > > Notice my offset is pretty marginal and rootdelay is rather low. If you > > can get your root delay down you should see your offset and stability > > improve. > > > > Brandon > > > > Well, overnight it only reset twice; - some improvement! > > Here is my complete ntp.conf: > > ------------------------------------------------------------ > # NOTES: > # - you should only have to update the server line below > # - if you start getting lines like 'restrict' and 'fudge' > # and you didnt add them, AND you run dhcpcd on your > # network interfaces, be sure to add '-Y -N' to the > # dhcpcd_ethX variables in /etc/conf.d/net > > # Name of the servers ntpd should sync with > # Please respect the access policy as stated by the responsible person. > #server ntp.example.tld iburst > > server pool.ntp.org > > ## > # A list of available servers can be found here: > # http://www.pool.ntp.org/ > # http://www.pool.ntp.org/#use > # A good way to get servers for your machine is: > # netselect -s 3 pool.ntp.org > ## > > # you should not need to modify the following paths > driftfile /var/lib/ntp/ntp.drift > > #server ntplocal.example.com prefer > #server timeserver.example.org > > # Warning: Using default NTP settings will leave your NTP > # server accessible to all hosts on the Internet. > > # If you want to deny all machines (including your own) > # from accessing the NTP server, uncomment: > #restrict default ignore > > > # To deny other machines from changing the > # configuration but allow localhost: > restrict default nomodify nopeer > restrict 127.0.0.1 > > > # To allow machines within your network to synchronize > # their clocks with your server, but ensure they are > # not allowed to configure the server or used as peers > # to synchronize against, uncomment this line. > # > #restrict 192.168.0.0 mask 255.255.255.0 nomodify nopeer notrap > ------------------------------------------------------------------- > > Notice I'm using pool.ntp.org. I thought that picked a random server. > In any event, I restarted ntpd and it picked a different server. > > ntpq -c peers is now: > -------------------------------------------------------------------------- > ---- > remote refid st t when poll reach delay offset jitter > ========================================================================== > ==== > *Time2.Stupi.SE .PPS 1 u 33 64 177 159.568 -4.188 5.881 > -------------------------------------------------------------------------- > ---- > > We'll see how this works out. > > Tony I can't speak for others but my experience with pool.ntp.org has been very poor. Some of the servers are close by and low latency and others are in far off lands. You may want to see if you can peer with a local university, military base, ISP, or company in addition to pool.ntp.org. There is a lot to say for reliable average latency over your list of peers. Adding a few more will really help out. Brandon -- Brandon Enright UCSD ACS/Network Operations bmenrigh@ucsd.edu -- gentoo-user@gentoo.org mailing list