Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
On Sunday 09 January 2011 00:34:33 Dale wrote: I read the man pages and even used google but the part about what to log didn't register with me. Basically, I need to tell it where to put the log file, which I did, then what I want it to log as well, which I missed. Sort of like the way portage does in make.conf. I didn't catch what the last part meant. I added that to config and restarted it. Will see if that does what I want. I think it will. I'm sure it will. I don't usually have logging switched on as it records large quantities of data, which would be useful in debugging but I don't need to do that. Not today, that is. Thanks for the help. Pleasure. -- Rgds Peter. Linux Counter 5290, 1994-04-23.
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
Way back when I first got an X2 they couldn't keep time for whatever
reason. I used to have to add something like clock=pmtmr notsc to the
kernel command line to make it behave.
That issue was fixed in a later kernel, but you could start adding clock
options to your kernel command line and pray that one of them jiggles
something in your favor.
A couple from the kernel docs:
clock=[BUGS=IA-32, HW] gettimeofday clocksource override.
[Deprecated]
Forces specified clocksource (if avaliable) to be used
when calculating gettimeofday(). If specified
clocksource is not avalible, it defaults to PIT.
Format: { pit | tsc | cyclone | pmtmr }
clocksource=Override the default clocksource
Format: string
Override the default clocksource and use the clocksource
with the name specified.
Some clocksource names to choose from, depending on
the platform:
[all] jiffies (this is the base, fallback clocksource)
[ACPI] acpi_pm
[ARM] imx_timer1,OSTS,netx_timer,mpu_timer2,
pxa_timer,timer3,32k_counter,timer0_1
[AVR32] avr32
[X86-32] pit,hpet,tsc,vmi-timer;
scx200_hrt on Geode; cyclone on IBM x440
[MIPS] MIPS
[PARISC] cr16
[S390] tod
[SH] SuperH
[SPARC64] tick
[X86-64] hpet,tsc
tsc=Disable clocksource-must-verify flag for TSC.
Format: string
[x86] reliable: mark tsc clocksource as reliable, this
disables clocksource verification at runtime.
Used to enable high-resolution timer mode on older
hardware, and in virtualized environment.
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
Peter Humphrey wrote: On Friday 07 January 2011 22:48:27 Dale wrote: Any other ideas? You could still try chrony. Success !! Check this out: r...@fireball / # ntpdate -b -u -q pool.ntp.org server 169.229.70.183, stratum 3, offset 0.009525, delay 0.12221 server 216.45.57.38, stratum 2, offset 0.000842, delay 0.12035 server 63.211.239.58, stratum 2, offset 0.009992, delay 0.09676 8 Jan 15:39:49 ntpdate[7402]: step time server 63.211.239.58 offset 0.009992 sec r...@fireball / # Now, with ntp, it logs to messages when it syncs, resets the clock and such. Does chrony do this somewhere too? I have this in my conf file: server 64.6.144.6 server 67.159.5.90 server 67.59.168.233 server 204.62.14.98 server 69.50.219.51 server 209.114.111.1 driftfile /etc/chrony.drift logdir /var/log/chrony I would think it would be either in messages or in /var/log/chrony but so far nothing is in there. This is from messages: r...@fireball / # cat /var/log/messages | grep chron | tail -n 50 Jan 8 03:16:52 localhost chronyd[21986]: chronyd exiting on signal Jan 8 03:16:53 localhost chronyd[23021]: chronyd version 1.24 starting Jan 8 03:16:53 localhost chronyd[23021]: Initial txc.tick=10006 txc.freq=94656 (1.44433594) txc.offset=0 = hz=100 shift_hz=7 Jan 8 03:16:53 localhost chronyd[23021]: set_config_hz=0 hz=100 shift_hz=7 basic_freq_scale=1.2800 nominal_tick=1 slew_delta_tick=833 max_tick_bias=1000 Jan 8 03:16:53 localhost chronyd[23021]: Linux kernel major=2 minor=6 patch=36 Jan 8 03:16:53 localhost chronyd[23021]: calculated_freq_scale=1. freq_scale=1. Jan 8 03:19:03 localhost chronyd[23021]: Selected source 64.6.144.6 Jan 8 15:24:56 localhost chronyd[23021]: chronyd exiting on signal Jan 8 15:24:56 localhost chronyd[1632]: chronyd version 1.24 starting Jan 8 15:24:56 localhost chronyd[1632]: Initial txc.tick=10011 txc.freq=2399519 (36.61375427) txc.offset=0 = hz=100 shift_hz=7 Jan 8 15:24:56 localhost chronyd[1632]: set_config_hz=0 hz=100 shift_hz=7 basic_freq_scale=1.2800 nominal_tick=1 slew_delta_tick=833 max_tick_bias=1000 Jan 8 15:24:56 localhost chronyd[1632]: Linux kernel major=2 minor=6 patch=36 Jan 8 15:24:56 localhost chronyd[1632]: calculated_freq_scale=1. freq_scale=1. Jan 8 15:27:07 localhost chronyd[1632]: Selected source 64.6.144.6 r...@fireball / # Ideas? I miss something somewhere? Do I have to create a file for it to log to as well? Dale :-) :-) P. S. I wonder why ntp and openntp didn't work?
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
On Saturday 08 January 2011 21:45:45 Dale wrote: Now, with ntp, it logs to messages when it syncs, resets the clock and such. Does chrony do this somewhere too? I have this in my conf file: [...] logdir /var/log/chrony You need to uncomment the next line too - the one that specifies what to log. Remember that an exclamation mark is a comment marker in chrony.conf. Do I have to create a file for it to log to as well? Nope. Just switch logging on, as above. If you have your syslog to output to VT12 you can read its log output there. In my case I use syslog-ng with the default config and VT12 switched on. P. S. I wonder why ntp and openntp didn't work? Haven't a clue, but I do remember shuddering at the complexity of configuring ntp, years ago. From reading this thread I get the impression it hasn't improved much since then. Here's my chrony.conf, minus comments; gate.ethnet is my gateway box: server uk.pool.ntp.org server gate.ethnet maxupdateskew 10 driftfile /etc/chrony/chrony.drift keyfile /etc/chrony/chrony.keys commandkey 1 dumponexit dumpdir /var/log/chrony initstepslew 30 gate.ethnet logdir /var/log/chrony log measurements statistics tracking rtc allow 192.168.2/24 allow 192.168.3/24 allow 192.168.4/24 logchange 0.5 cmdallow 127.0.0.1 rtcfile /etc/chrony/chrony.rtc rtconutc Incidentally, chronyd logs a cannot open error the first time it tries to write to a log or dump file; it seems to be harmless. HTH. I'm delighted you got something working! -- Rgds Peter. Linux Counter 5290, 1994-04-23.
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
On Saturday 08 January 2011 22:59:59 Peter Humphrey wrote: Incidentally, chronyd logs a cannot open error the first time it tries to write to a log or dump file; it seems to be harmless. Correction: that only applies to dump files; it creates log files quietly. -- Rgds Peter. Linux Counter 5290, 1994-04-23.
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
Peter Humphrey wrote: On Saturday 08 January 2011 21:45:45 Dale wrote: Now, with ntp, it logs to messages when it syncs, resets the clock and such. Does chrony do this somewhere too? I have this in my conf file: [...] logdir /var/log/chrony You need to uncomment the next line too - the one that specifies what to log. Remember that an exclamation mark is a comment marker in chrony.conf. Do I have to create a file for it to log to as well? Nope. Just switch logging on, as above. If you have your syslog to output to VT12 you can read its log output there. In my case I use syslog-ng with the default config and VT12 switched on. P. S. I wonder why ntp and openntp didn't work? Haven't a clue, but I do remember shuddering at the complexity of configuring ntp, years ago. From reading this thread I get the impression it hasn't improved much since then. Here's my chrony.conf, minus comments; gate.ethnet is my gateway box: server uk.pool.ntp.org server gate.ethnet maxupdateskew 10 driftfile /etc/chrony/chrony.drift keyfile /etc/chrony/chrony.keys commandkey 1 dumponexit dumpdir /var/log/chrony initstepslew 30 gate.ethnet logdir /var/log/chrony log measurements statistics tracking rtc allow 192.168.2/24 allow 192.168.3/24 allow 192.168.4/24 logchange 0.5 cmdallow 127.0.0.1 rtcfile /etc/chrony/chrony.rtc rtconutc Incidentally, chronyd logs a cannot open error the first time it tries to write to a log or dump file; it seems to be harmless. HTH. I'm delighted you got something working! I read the man pages and even used google but the part about what to log didn't register with me. Basically, I need to tell it where to put the log file, which I did, then what I want it to log as well, which I missed. Sort of like the way portage does in make.conf. I didn't catch what the last part meant. I added that to config and restarted it. Will see if that does what I want. I think it will. I didn't have to much trouble with ntp the first time. I remember adding the servers to the conf file then doing some other little setting and just starting it as a service. After that, every once in a while I would update the servers. Some of them would drop off and have to many hops or something and just needed to be replaced. I don't recall ever having trouble like this before. Mostly the problems I did have was with the servers disappearing, moving or problems with network delays. It sure failed me this time tho. :-( I'm going to try adding a line or two at a time until I get it set right then I'll post my config file in case someone else can use it as a reference. Thanks for the help. Dale :-) :-)
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
On Thu, 2011-01-06 at 21:31 -0600, Dale wrote: William Kenworthy wrote: Dale, can you post (a sanitised) version of what 'ntpq -p' gives after ntpd has been running for some time, and the sanitised result of 'ntptrace. Also include your full (sanitised) ntp.conf and /etc/conf.d/ntpd. This might help us see more detail of what is happening. BillK * sanitised - obfuscate public IP's only. I should have posted this a while back. Here we go: r...@fireball / # ntpq -p remote refid st t when poll reach delay offset jitter == +triangle.kansas 128.252.19.1 2 u4 64 127 56.270 673.749 238.194 +B1-66ER.matrix. 192.43.244.182 u 14 64 377 75.505 672.846 165.087 +kallisti.us 208.90.144.523 u 22 64 377 62.917 663.831 168.738 *kazilik.haqr.ne 209.51.161.238 2 u 42 64 377 66.483 653.962 166.119 r...@fireball / # ntptrace localhost: stratum 16, offset 0.00, synch distance 0.000240 r...@fireball / # Notice the difference in ntptrace between mine below and yours? The asterisk in your ntpq table indicates that is the chosen server - but not that it is actually locked to it - ntptrace is showing it is not locked. rattus ~ # ntptrace localhost: stratum 6, offset 0.001309, synch distance 0.160683 moriah: stratum 5, offset -0.004895, synch distance 0.155622 dns.iinet.net.au: stratum 4, offset 0.001463, synch distance 0.135967 ***Association ID 60244 unknown to server rattus ~ # Did you try the tinker panic 0 or -g arguments I suggested earlier? A third option is to increase the slew window rather than stepping - the default slew is less than what you are trying to force it to do so it fails and gives up. rattus ~ # ntptrace localhost: stratum 6, offset 0.001309, synch distance 0.160683 moriah: stratum 5, offset -0.004895, synch distance 0.155622 dns.iinet.net.au: stratum 4, offset 0.001463, synch distance 0.135967 ***Association ID 60244 unknown to server rattus ~ # I would suggest stopping ntpd and modifying the ntp.conf file as suggested, deleting /etc/adjtime and the drift file then rebooting. Run for a few hours and see if it still jumps time. ntpd will correct some extreem time issues but it needs to be properly configured. If it is actually jumping time rather than incorrect drift/slew/adjustime issues then you need to track down why - good luck with that! So far all I am seeing is a clock thats off too far to correct and isnt being allowed to correct by the config BillK
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
William Kenworthy wrote: Notice the difference in ntptrace between mine below and yours? The asterisk in your ntpq table indicates that is the chosen server - but not that it is actually locked to it - ntptrace is showing it is not locked. rattus ~ # ntptrace localhost: stratum 6, offset 0.001309, synch distance 0.160683 moriah: stratum 5, offset -0.004895, synch distance 0.155622 dns.iinet.net.au: stratum 4, offset 0.001463, synch distance 0.135967 ***Association ID 60244 unknown to server rattus ~ # Did you try the tinker panic 0 or -g arguments I suggested earlier? A third option is to increase the slew window rather than stepping - the default slew is less than what you are trying to force it to do so it fails and gives up. rattus ~ # ntptrace localhost: stratum 6, offset 0.001309, synch distance 0.160683 moriah: stratum 5, offset -0.004895, synch distance 0.155622 dns.iinet.net.au: stratum 4, offset 0.001463, synch distance 0.135967 ***Association ID 60244 unknown to server rattus ~ # I would suggest stopping ntpd and modifying the ntp.conf file as suggested, deleting /etc/adjtime and the drift file then rebooting. Run for a few hours and see if it still jumps time. ntpd will correct some extreem time issues but it needs to be properly configured. If it is actually jumping time rather than incorrect drift/slew/adjustime issues then you need to track down why - good luck with that! So far all I am seeing is a clock thats off too far to correct and isnt being allowed to correct by the config BillK I added the -g option but have no idea why that will change anything. According to the man page, it is for when the clock is more than 1000s off which makes it outside the range ntp will change. Mine is off only a few seconds and most of the time less than one second. So I fail to understand why this option is going to do any good here. Maybe you can explain it more? It ran all night and most of this morning. It's still resetting like it has in the past but not like on my old rig. Before I went to sleep I reset the drift-file to about half what it set it to. It set it back to 500 so it is changing. So, ntp can set the clock, it can change the drift file value but it can't adjust the clock cycles to speed it up or slow it down. I think I'm missing something in the kernel or something. I may compare my kernel config files later on when I get some time. Try to rule that out. Dale :-) :-)
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
Dale wrote: I added the -g option but have no idea why that will change anything. According to the man page, it is for when the clock is more than 1000s off which makes it outside the range ntp will change. Mine is off only a few seconds and most of the time less than one second. So I fail to understand why this option is going to do any good here. Maybe you can explain it more? It ran all night and most of this morning. It's still resetting like it has in the past but not like on my old rig. Before I went to sleep I reset the drift-file to about half what it set it to. It set it back to 500 so it is changing. So, ntp can set the clock, it can change the drift file value but it can't adjust the clock cycles to speed it up or slow it down. I think I'm missing something in the kernel or something. I may compare my kernel config files later on when I get some time. Try to rule that out. Dale :-) :-) I added the -g option and it has been running all day. It's no different than it was. It's still syncing often and off by more than it should be as well. Any other ideas? Dale :-) :-)
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
On Friday 07 January 2011 22:48:27 Dale wrote: Any other ideas? You could still try chrony. -- Rgds Peter. Linux Counter 5290, 1994-04-23.
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
Peter Humphrey wrote: On Friday 07 January 2011 22:48:27 Dale wrote: Any other ideas? You could still try chrony. Well, I tried ntp, openntp, the unstable ntp but I may give that a shot too. Heck, nothing else is working so couldn't hurt to try I guess. May wait until tomorrow tho. I'm tired. Thanks. I didn't know that even existed. Dale :-) :-)
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
On 1/5/2011 12:04 AM, Thanasis wrote: I think you should prefer openntpd over ntpd, because I think openntpd is developed by openbsd, which means more secure ... I tried openntp a couple years ago. It was a giant pain in the ass. IIRC it was combination of crap defaults, poor docs, and plain not working. I think this was over five years ago and doubtfully thing have improved, but I definitely wasn't impressed at the time. kashani
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
kashani wrote: On 1/5/2011 12:04 AM, Thanasis wrote: I think you should prefer openntpd over ntpd, because I think openntpd is developed by openbsd, which means more secure ... I tried openntp a couple years ago. It was a giant pain in the ass. IIRC it was combination of crap defaults, poor docs, and plain not working. I think this was over five years ago and doubtfully thing have improved, but I definitely wasn't impressed at the time. kashani It is a basic program for sure. Commands that I used before with ntp were missing. The plain ntp has a lot more options and more commands for seeing what is going on while openntp does not have much. I think either would work here if I didn't have some underlying issue somewhere. Dale :-) :-)
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
On Thu, 2011-01-06 at 14:46 -0600, Dale wrote: kashani wrote: On 1/5/2011 12:04 AM, Thanasis wrote: I think you should prefer openntpd over ntpd, because I think openntpd is developed by openbsd, which means more secure ... I tried openntp a couple years ago. It was a giant pain in the ass. IIRC it was combination of crap defaults, poor docs, and plain not working. I think this was over five years ago and doubtfully thing have improved, but I definitely wasn't impressed at the time. kashani It is a basic program for sure. Commands that I used before with ntp were missing. The plain ntp has a lot more options and more commands for seeing what is going on while openntp does not have much. I think either would work here if I didn't have some underlying issue somewhere. Dale :-) :-) Dale, can you post (a sanitised) version of what 'ntpq -p' gives after ntpd has been running for some time, and the sanitised result of 'ntptrace. Also include your full (sanitised) ntp.conf and /etc/conf.d/ntpd. This might help us see more detail of what is happening. BillK * sanitised - obfuscate public IP's only. -- William Kenworthy bi...@iinet.net.au Home in Perth!
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
William Kenworthy wrote: Dale, can you post (a sanitised) version of what 'ntpq -p' gives after ntpd has been running for some time, and the sanitised result of 'ntptrace. Also include your full (sanitised) ntp.conf and /etc/conf.d/ntpd. This might help us see more detail of what is happening. BillK * sanitised - obfuscate public IP's only. I should have posted this a while back. Here we go: r...@fireball / # ntpq -p remote refid st t when poll reach delay offset jitter == +triangle.kansas 128.252.19.1 2 u4 64 127 56.270 673.749 238.194 +B1-66ER.matrix. 192.43.244.182 u 14 64 377 75.505 672.846 165.087 +kallisti.us 208.90.144.523 u 22 64 377 62.917 663.831 168.738 *kazilik.haqr.ne 209.51.161.238 2 u 42 64 377 66.483 653.962 166.119 r...@fireball / # ntptrace localhost: stratum 16, offset 0.00, synch distance 0.000240 r...@fireball / # This is ntp.conf but I omitted the parts that are commented out. server 64.6.144.6 server 67.159.5.90 server 67.59.168.233 server 204.62.14.98 driftfile/var/lib/ntp/ntp.drift restrict default nomodify nopeer restrict 127.0.0.1 This makes sense if you read the command: r...@fireball / # cat /var/log/messages | grep ntp | tail -n 30 Jan 6 19:58:14 localhost ntpd[3017]: Attemping to register mDNS Jan 6 19:58:14 localhost ntpd[3017]: *** WARNING *** The program 'ntpd' uses the Apple Bonjour compatibility layer of Avahi. Jan 6 19:58:14 localhost ntpd[3017]: *** WARNING *** Please fix your application to use the native API of Avahi! Jan 6 19:58:14 localhost ntpd[3017]: *** WARNING *** For more information see http://0pointer.de/avahi-compat?s=libdns_sde=ntpd Jan 6 19:58:14 localhost ntpd[3019]: precision = 1.000 usec Jan 6 19:58:14 localhost ntpd[3019]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled Jan 6 19:58:14 localhost ntpd[3019]: Listening on interface #1 wildcard, ::#123 Disabled Jan 6 19:58:14 localhost ntpd[3019]: Listening on interface #2 eth0, fe80::1e6f:65ff:fe4c:91c7#123 Enabled Jan 6 19:58:14 localhost ntpd[3019]: Listening on interface #3 lo, ::1#123 Enabled Jan 6 19:58:14 localhost ntpd[3019]: Listening on interface #4 lo, 127.0.0.1#123 Enabled Jan 6 19:58:14 localhost ntpd[3019]: Listening on interface #5 eth0, 192.168.2.5#123 Enabled Jan 6 19:58:14 localhost ntpd[3019]: kernel time sync status 2040 Jan 6 19:58:14 localhost ntpd[3019]: frequency initialized 500.000 PPM from /var/lib/ntp/ntp.drift Jan 6 20:02:33 localhost ntpd[3019]: synchronized to 67.59.168.233, stratum 3 Jan 6 20:02:33 localhost ntpd[3019]: time reset +0.237917 s Jan 6 20:02:33 localhost ntpd[3019]: kernel time sync status change 2001 Jan 6 20:07:31 localhost ntpd[3019]: synchronized to 67.159.5.90, stratum 2 Jan 6 20:13:57 localhost ntpd[3019]: synchronized to 204.62.14.98, stratum 2 Jan 6 20:17:34 localhost ntpd[3019]: time reset +0.567387 s Jan 6 20:24:05 localhost ntpd[3019]: synchronized to 67.159.5.90, stratum 2 Jan 6 20:27:05 localhost ntpd[3019]: synchronized to 204.62.14.98, stratum 2 Jan 6 20:31:40 localhost ntpd[3019]: synchronized to 67.159.5.90, stratum 2 Jan 6 20:35:33 localhost ntpd[3019]: time reset +0.604521 s Jan 6 20:44:29 localhost ntpd[3019]: synchronized to 67.159.5.90, stratum 2 Jan 6 20:47:44 localhost ntpd[3019]: synchronized to 204.62.14.98, stratum 2 Jan 6 20:55:22 localhost ntpd[3019]: time reset +0.663361 s Jan 6 21:01:22 localhost ntpd[3019]: synchronized to 204.62.14.98, stratum 2 Jan 6 21:04:05 localhost ntpd[3019]: synchronized to 67.159.5.90, stratum 2 Jan 6 21:08:40 localhost ntpd[3019]: synchronized to 204.62.14.98, stratum 2 Jan 6 21:17:01 localhost ntpd[3019]: time reset +0.676538 s r...@fireball / # Notice it is off about .6 seconds every 15 to 20 minutes or so? It never gets any closer than this either. I let it run for a good day the other day and it was still the same. On my old rig, it would get to a point where the corrections were smaller and the syncs were father apart. I have seen it go for hours between syncs and be only .01 or .02 seconds off. My old rig wouldn't sync so often either. The drift file would also change and be some rather odd numbers. The file on this rig never changes and looks like some sort of a default value. Speaking of: r...@fireball / # cat /var/lib/ntp/ntp.drift 500.000 r...@fireball / # This is the adjtime file from a good ways back: r...@fireball / # cat /etc/adjtime 0.00 1294340368 0.00 1294340368 UTC r...@fireball / # And the current one after some updates: r...@fireball / # cat /etc/adjtime 0.00 1294365381 0.00 1294365381 UTC r...@fireball / # Does any of this put the light on something I may be missing? I started with a copy of ntp.conf from my old rig. I did change the servers but I change them sometimes anyway. I use
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
On Fri, 7 Jan 2011 14:31:52 Dale wrote: William Kenworthy wrote: Dale, can you post (a sanitised) version of what 'ntpq -p' gives after ntpd has been running for some time, and the sanitised result of 'ntptrace. Also include your full (sanitised) ntp.conf and /etc/conf.d/ntpd. This might help us see more detail of what is happening. BillK * sanitised - obfuscate public IP's only. I should have posted this a while back. Here we go: r...@fireball / # ntpq -p remote refid st t when poll reach delay offset jitter === === +triangle.kansas 128.252.19.1 2 u4 64 127 56.270 673.749 238.194 +B1-66ER.matrix. 192.43.244.182 u 14 64 377 75.505 672.846 165.087 +kallisti.us 208.90.144.523 u 22 64 377 62.917 663.831 168.738 *kazilik.haqr.ne 209.51.161.238 2 u 42 64 377 66.483 653.962 166.119 r...@fireball / # ntptrace localhost: stratum 16, offset 0.00, synch distance 0.000240 r...@fireball / # This is ntp.conf but I omitted the parts that are commented out. server 64.6.144.6 server 67.159.5.90 server 67.59.168.233 server 204.62.14.98 Have you tried switching servers? I'm using server 0.au.pool.ntp.org server 1.au.pool.ntp.org Try the equivalent for your location, or there are 0.gentoo.pool.ntp.org and so on. -- Reverend Paul Colquhoun, ULC.http://andor.dropbear.id.au/~paulcol Before you criticize someone, you should walk a mile in their shoes. Then, when you do, you'll be a mile away, and you'll have their shoes.
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
Paul Colquhoun wrote: On Fri, 7 Jan 2011 14:31:52 Dale wrote: This is ntp.conf but I omitted the parts that are commented out. server 64.6.144.6 server 67.159.5.90 server 67.59.168.233 server 204.62.14.98 Have you tried switching servers? I'm using server 0.au.pool.ntp.org server 1.au.pool.ntp.org Try the equivalent for your location, or there are 0.gentoo.pool.ntp.org and so on. I have. I started out with the same servers on my old rig and changed them to see if it would matter a week or so ago. I use this command to get the best servers: netselect -s 3 pool.ntp.org That generally works pretty well. I try to update them every once in a while. I'm thinking about removing the router and hooking directly to my DSL modem. That's the only thing that has changed from the old rig to the new rig. This is how close the old rig is and it is hooked to the router too: r...@smoker / # ntpdate -b -u -q pool.ntp.org server 72.26.125.125, stratum 2, offset -0.87, delay 0.09828 server 64.34.218.21, stratum 2, offset -0.002207, delay 0.09799 server 149.20.68.17, stratum 2, offset 0.009124, delay 0.13466 6 Jan 23:23:31 ntpdate[15816]: step time server 64.34.218.21 offset -0.002207 sec r...@smoker / # According to the log, it synced a hour or so ago and the previous sync was about 7 hours before that. Now why can't my new rig do that? Dale :-) :-)
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
I think you should prefer openntpd over ntpd, because I think openntpd is developed by openbsd, which means more secure ...
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
Am 05.01.2011 06:00, schrieb Dale: William Kenworthy wrote: Is the clock almost in sync? - if its too far out ntp will silently fail to sync (by design - large scale time steps can be destructive for heavily active databases for instance) That's what i meant in my earlier post and what the extract of your logfile confirms. Check out the -g option to ntpd in 'man ntpd' or 'tinker panic 0' in ntp.conf Also, has ntp.conf specified a writable frift file in a directory that exists? ntp can be VERY complex when it doesnt just work :) +1 It syncs and adjusts the time. It just doesn't do it like my older rig. My old rig, when I booted it up, ntp would sync and in about a hour or so it would be accurate enough that it would only sync a few times a day. Since I have long uptimes, that worked out well. With this new rig, it syncs about every ten to 15 minutes and adjusts and just keeps doing the same thing. It never sets the drift file to a setting that allows it to go more than ten or fifteen minutes without resetting the clock. This is what is in messages: If i remember right your new rig is AMD-Phenom based?! - then just have a look at http://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.4.2.7. If your clocksource is the tsc it's possible youre affected by this problem. At http://www.ep.ph.bham.ac.uk/general/support/adjtimex.html#issues is a nice illustration of the affect. Steffen
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
Steffen Loos wrote: If i remember right your new rig is AMD-Phenom based?! - then just have a look at http://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.4.2.7. If your clocksource is the tsc it's possible youre affected by this problem. At http://www.ep.ph.bham.ac.uk/general/support/adjtimex.html#issues is a nice illustration of the affect. Steffen You remember correctly. I read some of that, actually ran across it while googling myself, and I don't know for sure if it was the problem or not. I unmerged ntp and emerged openntp. That's in a separate post. Going to see if that works. Dale :-) :-)
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
On Tuesday 04 January 2011 01:31:27 Dale wrote: Anybody else ran into this? Am I missing something that is different on a 64 bit rig? I discovered chrony some years ago, which has a sophisticated clock slewing mechanism, and haven't used ntp since. Chrony runs on my gateway machine to maintain a stable time source for the boxes inside, which are a mixture of 32- and 64-bit. I just don't think about timekeeping any more. You might want to give it a try. -- Rgds Peter. Linux Counter 5290, 1994-04-23.
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
Am 04.01.2011 02:31, schrieb Dale: Hi, I been watching my clock here for a while. On my old rig, ntp kept the clock set very, very well. This rig seems to have issues. I tried the stable version of ntp and it just seems to keep resetting the time but not adjusting the drift file at all. I even adjusted manually once and my entry was better than the one it made. Maybe the drift of your systemclock is to large. E.g. in (full) virtuell machines i experienced this problem. In such a case ntp only resets the clock regulary (time reset +2.171765 s in /var/log/ntp).[1] I have solved it with adjtimex as i speedup the systemclock a little bit (params: tick and freq). Since ntpd is working as expected again. [2] gave me the hint. Steffen [1] man 8 ntpd (just look for maximum slew rate) [2] http://www.ep.ph.bham.ac.uk/general/support/adjtimex.html
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
Peter Humphrey wrote: On Tuesday 04 January 2011 01:31:27 Dale wrote: Anybody else ran into this? Am I missing something that is different on a 64 bit rig? I discovered chrony some years ago, which has a sophisticated clock slewing mechanism, and haven't used ntp since. Chrony runs on my gateway machine to maintain a stable time source for the boxes inside, which are a mixture of 32- and 64-bit. I just don't think about timekeeping any more. You might want to give it a try. I'll give it some thought. I was the same way about ntp on my old rig. I set it up and it just worked. It just doesn't work on this rig. I let the unstable package run a good while and it never did create a drift file. I emerged the stable version and it created a drift file but it is still reseting almost 1 second every ten minutes. On the old rig, once it got the drift file set up with a good value, it only synced a few times a day and set maybe once a day and it was very little. On the new rig, its having to reset every few minutes and still can't get it right. This is weird. Dale :-) :-)
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
Is the clock almost in sync? - if its too far out ntp will silently fail to sync (by design - large scale time steps can be destructive for heavily active databases for instance) Check out the -g option to ntpd in 'man ntpd' or 'tinker panic 0' in ntp.conf Also, has ntp.conf specified a writable frift file in a directory that exists? ntp can be VERY complex when it doesnt just work :) BillK On Mon, 2011-01-03 at 19:31 -0600, Dale wrote: Hi, I been watching my clock here for a while. On my old rig, ntp kept the clock set very, very well. This rig seems to have issues. I tried the stable version of ntp and it just seems to keep resetting the time but not adjusting the drift file at all. I even adjusted manually once and my entry was better than the one it made. I then decided to try the latest unstable ntp to see if maybe it would work better. I emerged ntp, renamed the drift file and started the service. That was several hours ago and it has yet to even create the drift file. It also puts nothing in the log file except that it started and is using ports and the normal stuff. No syncing or anything like the older version. Also, I copied the ntp.conf file over from the old rig. I would think they would work pretty much the same. Same program, same config and hopefully same results. First version tried: net-misc/ntp-4.2.4_p7-r1 Current unstable version: net-misc/ntp-4.2.6_p2-r1 When I looked at the ntp website, it said it should sync much faster than the old one. Basically it is minutes instead of hours. So far this is not the case. Anybody else ran into this? Am I missing something that is different on a 64 bit rig? Thanks. Dale :-) :-) -- William Kenworthy bi...@iinet.net.au Home in Perth!
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
William Kenworthy wrote: Is the clock almost in sync? - if its too far out ntp will silently fail to sync (by design - large scale time steps can be destructive for heavily active databases for instance) Check out the -g option to ntpd in 'man ntpd' or 'tinker panic 0' in ntp.conf Also, has ntp.conf specified a writable frift file in a directory that exists? ntp can be VERY complex when it doesnt just work :) BillK It syncs and adjusts the time. It just doesn't do it like my older rig. My old rig, when I booted it up, ntp would sync and in about a hour or so it would be accurate enough that it would only sync a few times a day. Since I have long uptimes, that worked out well. With this new rig, it syncs about every ten to 15 minutes and adjusts and just keeps doing the same thing. It never sets the drift file to a setting that allows it to go more than ten or fifteen minutes without resetting the clock. This is what is in messages: Jan 4 21:09:26 localhost ntpd[10181]: time reset +0.636966 s Jan 4 21:16:25 localhost ntpd[10181]: synchronized to 67.159.5.90, stratum 2 Jan 4 21:22:53 localhost ntpd[10181]: synchronized to 64.6.144.6, stratum 2 Jan 4 21:26:01 localhost ntpd[10181]: time reset +0.567349 s Jan 4 21:30:25 localhost ntpd[10181]: synchronized to 67.159.5.90, stratum 2 Jan 4 21:41:09 localhost ntpd[10181]: time reset +0.603411 s Jan 4 21:45:32 localhost ntpd[10181]: synchronized to 64.6.144.6, stratum 2 Jan 4 21:51:56 localhost ntpd[10181]: synchronized to 67.159.5.90, stratum 2 Jan 4 21:54:39 localhost ntpd[10181]: synchronized to 64.6.144.6, stratum 2 Jan 4 21:56:17 localhost ntpd[10181]: time reset +0.604867 s Jan 4 22:03:13 localhost ntpd[10181]: synchronized to 67.159.5.90, stratum 2 Jan 4 22:07:18 localhost ntpd[10181]: synchronized to 64.6.144.6, stratum 2 Jan 4 22:11:56 localhost ntpd[10181]: time reset +0.649596 s Jan 4 22:16:47 localhost ntpd[10181]: synchronized to 67.59.168.233, stratum 3 Jan 4 22:20:06 localhost ntpd[10181]: synchronized to 67.159.5.90, stratum 2 Jan 4 22:24:24 localhost ntpd[10181]: synchronized to 64.6.144.6, stratum 2 Jan 4 22:28:37 localhost ntpd[10181]: synchronized to 67.159.5.90, stratum 2 Jan 4 22:28:46 localhost ntpd[10181]: time reset +0.621297 s Jan 4 22:37:41 localhost ntpd[10181]: synchronized to 67.159.5.90, stratum 2 Now on my old system, it would adjust the drift file and the adjustments would get smaller and smaller. On the new rig, as you can see it stays about the same. I would like it to get to a point where it doesn't have to sync so often. I read on the website where they are needing more servers to help with the load and I don't want to be one of the ones putting a load on it. I downgraded back to a stable ntp and it did generate a drift file after a while. The messages above are from the stable ntp. I think I have it configured correctly but just need to add a option somewhere to make it do better. I'm even wondering if it could be something kernel related. Maybe I forgot to enable something. Dale :-) :-)
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
Try the following and see if it resets time correctly date 0101010101 /etc/init.d/ntpd restart date
Re: [gentoo-user] Latest unstable ntp not generating ntp.drift file.
on 01/05/2011 09:39 AM Dale wrote the following: Thanasis wrote: date 0101010101 /etc/init.d/ntpd restart date I got this: Jan 1 01:05:16 localhost ntpd[5709]: time correction of 315880203 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. I was pretty sure it would exceed its adjustment but thought it worth a try. At least it complains. lol Dale :-) :-) Have you set -s in its startup options and does directory /var/empty exist? Here is my /etc/conf.d/ntpd : # /etc/conf.d/ntpd: config file for openntpd's ntpd NTPD_HOME=/var/empty # See ntpd(8) man page ... some popular options: # -s Set the time immediately at startup NTPD_OPTS=-s
[gentoo-user] Latest unstable ntp not generating ntp.drift file.
Hi, I been watching my clock here for a while. On my old rig, ntp kept the clock set very, very well. This rig seems to have issues. I tried the stable version of ntp and it just seems to keep resetting the time but not adjusting the drift file at all. I even adjusted manually once and my entry was better than the one it made. I then decided to try the latest unstable ntp to see if maybe it would work better. I emerged ntp, renamed the drift file and started the service. That was several hours ago and it has yet to even create the drift file. It also puts nothing in the log file except that it started and is using ports and the normal stuff. No syncing or anything like the older version. Also, I copied the ntp.conf file over from the old rig. I would think they would work pretty much the same. Same program, same config and hopefully same results. First version tried: net-misc/ntp-4.2.4_p7-r1 Current unstable version: net-misc/ntp-4.2.6_p2-r1 When I looked at the ntp website, it said it should sync much faster than the old one. Basically it is minutes instead of hours. So far this is not the case. Anybody else ran into this? Am I missing something that is different on a 64 bit rig? Thanks. Dale :-) :-)
