Re: [gentoo-user] NTP problem
On Wed, 2006-02-22 at 01:32 -0600, Anthony E. Caudel wrote: My system was off about 10 days and when I turned it back on, I began getting these messages in my logwatch: Time Reset time stepped -0.133773 time stepped -0.662954 time stepped +0.271164 time stepped +0.461200 time stepped -0.787647 snip Time Reset 25 times (total: -1.239782 s average: -0.049591 s) **Unmatched Entries** synchronized to 80.35.31.228, stratum 3 synchronized to 80.35.31.228, stratum 4 snip synchronized to 80.35.31.228, stratum 4 synchronized to 80.35.31.228, stratum 3 Listening on interface wildcard, 0.0.0.0#123 Listening on interface eth0, 192.168.1.100#123 Listening on interface lo, 127.0.0.1#123 kernel time sync status 0040 I rebooted thinking it needed to stabilize but it still gets them. I have ntp-client and ntpd both in the default runlevel. This seems like an awful high number of resets. Much more than I used to get. Tony Those are some pretty big jumps. What does ntpq -c peers and ntpq -c rv output? Also, what are the first few lines (the restrict entries) of your ntp.conf? Brandon -- Brandon Enright UCSD ACS/Network Operations [EMAIL PROTECTED] -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] NTP problem
On Wed, 2006-02-22 at 02:41 -0600, Anthony E. Caudel wrote: Brandon Enright wrote: On Wed, 2006-02-22 at 01:32 -0600, Anthony E. Caudel wrote: My system was off about 10 days and when I turned it back on, I began getting these messages in my logwatch: Time Reset time stepped -0.133773 time stepped -0.662954 time stepped +0.271164 time stepped +0.461200 time stepped -0.787647 snip Time Reset 25 times (total: -1.239782 s average: -0.049591 s) **Unmatched Entries** synchronized to 80.35.31.228, stratum 3 synchronized to 80.35.31.228, stratum 4 snip synchronized to 80.35.31.228, stratum 4 synchronized to 80.35.31.228, stratum 3 Listening on interface wildcard, 0.0.0.0#123 Listening on interface eth0, 192.168.1.100#123 Listening on interface lo, 127.0.0.1#123 kernel time sync status 0040 I rebooted thinking it needed to stabilize but it still gets them. I have ntp-client and ntpd both in the default runlevel. This seems like an awful high number of resets. Much more than I used to get. Tony Those are some pretty big jumps. What does ntpq -c peers and ntpq -c rv output? Also, what are the first few lines (the restrict entries) of your ntp.conf? Brandon ntpq -c peers: remote refid st t when poll reach delay offset jitter == *ntp3.usv.ro .PPS. 1 u 70 1024 377 203.0807.338 1.485 ntpq -rv: assID=0 status=06a4 leap_none, sync_ntp, 10 events, event_peer/strat_chg, version=ntpd [EMAIL PROTECTED] Thu Dec 8 09:35:31 CST 2005 (1)?, processor=i686, system=Linux/2.6.15-gentoo-r1, leap=00, stratum=2, precision=-20, rootdelay=203.080, rootdispersion=34.319, peer=35268, refid=80.96.120.249, reftime=c7a69e5a.a3227d02 Wed, Feb 22 2006 2:24:58.637, poll=10, clock=0xc7a6a0b6.78a5bd94, state=4, offset=7.338, frequency=35.514, noise=2.162, jitter=0.891, stability=64.582 ntp.conf: restrict default nomodify nopeer restrict 127.0.0.1 Tony 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 [EMAIL PROTECTED] 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 -- Brandon Enright UCSD ACS/Network Operations [EMAIL PROTECTED] -- gentoo-user@gentoo.org mailing list
RE: [gentoo-user] NTP problem
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] -- gentoo-user@gentoo.org mailing list
RE: [gentoo-user] unmerge without deleting?
Not directly that I'm aware of. You could build a binary package of it so that you re-emerge your binary at a later date. You may also want to look into ccache as it can dramatically speed up a re-compile of a package. --Brandon -Original Message- From: Robert Persson [mailto:[EMAIL PROTECTED] Sent: Sunday, April 17, 2005 9:33 PM To: gentoo-user@lists.gentoo.org Subject: [gentoo-user] unmerge without deleting? Is it possible to unmerge an ebuild without deleting the files? In other words, is it possible to unmerge to a package in case you want to re-merge it in the future without having to rebuild? Thanks Robert -- Robert Persson The illusion of freedom will continue as long as it's profitable to continue the illusion. At the point where the illusion becomes too expensive to maintain, they will just take down the scenery, they will pull back the curtains, they will move the tables and chairs out of the way, and you will see the brick wall at the back of the theatre. - Frank Zappa -- gentoo-user@gentoo.org mailing list -- gentoo-user@gentoo.org mailing list
