[gentoo-user] Latest unstable ntp not generating ntp.drift file.
Dale
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
:-) :-)
Peter Humphrey
> 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.
Steffen Loos
> 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.
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
Dale
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
:-) :-)
William Kenworthy
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
--
William Kenworthy <bi...@iinet.net.au>
Home in Perth!
Thanasis
> 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"
Thanasis
is developed by openbsd, which means more secure ...
Steffen Loos
> 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" :)
+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
Francesco Talamona
> 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.
Maybe you copied over /etc/adjtime from the previous machine. I would
try to regenerate it...
Ciao
Francesco
--
Linux Version 2.6.36-gentoo-r6, Compiled #2 SMP PREEMPT Mon Jan 3
11:54:58 CET 2011
Two 1GHz AMD Athlon 64 Processors, 4GB RAM, 4021.84 Bogomips Total
aemaeth
Dale
> On Wednesday 05 January 2011, Dale wrote:
>
>> 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.
>>
> Maybe you copied over /etc/adjtime from the previous machine. I would
> try to regenerate it...
>
> Ciao
> Francesco
>
I'm sure I didn't copy that. I copied ntp.conf but that is all. I
didn't even notice that one being there. I got to see what purpose that
has.
I may delete it tho and see what happens. It would generate a new one
if I restart the service correct?
Dale
:-) :-)
Dale
Little update. I tried every version of ntp in the tree including one
released in the past few days that was supposed to have some more bug
fixes. No joy. Same thing in the log file and ntp.drift. It just
would not adjust the clock like it should and did on my old rig.
I unmerged ntp and emerged openntpd. Does this look normal?
Jan 5 21:59:02 localhost ntpd[11410]: ntp engine ready
Jan 5 21:59:22 localhost ntpd[11410]: peer 72.26.217.210 now valid
Jan 5 21:59:23 localhost ntpd[11410]: peer 169.229.70.95 now valid
Jan 5 21:59:26 localhost ntpd[11410]: peer 149.20.54.20 now valid
Jan 5 22:00:24 localhost ntpd[11409]: adjusting local clock by 0.790318s
Jan 5 22:01:53 localhost ntpd[11410]: ntp engine exiting
Jan 5 22:01:53 localhost ntpd[11409]: dispatch_imsg in main: pipe closed
Jan 5 22:01:53 localhost ntpd[11409]: Lost child: child exited
Jan 5 22:01:53 localhost ntpd[11409]: Terminating
Jan 5 22:01:53 localhost ntpd[11581]: ntp engine ready
Jan 5 22:02:10 localhost ntpd[11581]: peer 173.203.202.87 now valid
Jan 5 22:02:13 localhost ntpd[11581]: peer 68.49.223.120 now valid
Jan 5 22:02:13 localhost ntpd[11581]: peer 64.22.86.210 now valid
Jan 5 22:02:14 localhost ntpd[11581]: peer 67.59.168.233 now valid
Jan 5 22:02:16 localhost ntpd[11581]: peer 64.6.144.6 now valid
Jan 5 22:02:16 localhost ntpd[11581]: peer 67.159.5.90 now valid
Jan 5 22:03:13 localhost ntpd[11579]: adjusting local clock by 0.828631s
Jan 5 22:03:56 localhost ntpd[11581]: peer 64.6.144.6 now invalid
Jan 5 22:06:15 localhost ntpd[11579]: adjusting local clock by 0.842206s
Jan 5 22:08:57 localhost ntpd[11579]: adjusting local clock by 0.872386s
Jan 5 22:13:06 localhost ntpd[11579]: adjusting local clock by 0.900218s
Jan 5 22:14:45 localhost ntpd[11581]: peer 64.6.144.6 now valid
Jan 5 22:17:22 localhost ntpd[11579]: adjusting local clock by -11.516304s
Jan 5 22:17:22 localhost ntpd[11581]: clock is now synced
Jan 5 22:18:56 localhost ntpd[11581]: peer 64.6.144.6 now invalid
Jan 5 22:20:38 localhost ntpd[11579]: adjusting local clock by -23.876356s
Jan 5 22:20:38 localhost ntpd[11581]: clock is now unsynced
Jan 5 22:23:46 localhost ntpd[11579]: adjusting local clock by -23.624100s
root@fireball / #
I assume it will eventually sync up. It hasn't been running very long
so I'll give it a while. It does appear to me that it is working
better. I still would like to know why ntp failed me all of a sudden.
Thanks.
:-) :-)
Dale
>
> 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
:-) :-)
Francesco Talamona
It makes the hardware clock take care of the systematic drift. If a
wrong value is stored in it, it can interfere with ntp in the way you
described: every time ntp runs it always corrects for the same amount.
From man 8 hwclock:
"The Hardware Clock is usually not very accurate. However, much of
its inaccuracy is completely predictable - it gains or loses the same
amount of time every day.
This is called systematic drift. hwclock's "adjust" function
lets you make systematic corrections to correct the systematic drift."
and:
"It is good to do a hwclock --adjust just before the hwclock --hctosys
at system startup time, and maybe periodically while the system is
running via cron."
This is my "recipe":
let ntpdate sync your clock, then /sbin/hwclock --systohc
and you are done. From that moment on ntp takes care of the non
systematic error, while the drift is zeroed "by hwclock".
Somewhere it is suggested to run /sbin/hwclock --adjust once a year.
I experienced what you describe when I built my new machine, I had
copied /etc/adjtime (without knowing what it was) from the previous, it
took me a good deal of googling...
BTW I don't have ntp.drift, I only use ntpdate and the clock is always
correct.
HTH
Dale
Well, I tried openntp for a good while last night and it was worse than
ntp. It was adjusting the clock by something like 20 seconds at a
time. Even ntp wasn't that bad. I went back to plain ntp. This is
what ntp has sent to messages overnight while I was napping:
Jan 6 00:13:21 localhost ntpd[23712]: ntpd 4.2...@1.2290-o Thu Jan 6
05:41:55 UTC 2011 (1)
Jan 6 00:13:21 localhost ntpd[23713]: proto: precision = 0.102 usec
Jan 6 00:13:21 localhost ntpd[23713]: Listen and drop on 0 v4wildcard
0.0.0.0 UDP 123
Jan 6 00:13:21 localhost ntpd[23713]: Listen and drop on 1 v6wildcard
:: UDP 123
Jan 6 00:13:21 localhost ntpd[23713]: Listen normally on 2 lo 127.0.0.1
UDP 123
Jan 6 00:13:21 localhost ntpd[23713]: Listen normally on 3 eth0
192.168.2.5 UDP 123
Jan 6 00:13:21 localhost ntpd[23713]: Listen normally on 4 eth0
fe80::1e6f:65ff:fe4c:91c7 UDP 123
Jan 6 00:13:21 localhost ntpd[23713]: Listen normally on 5 lo ::1 UDP 123
Jan 6 00:13:21 localhost ntpd[23713]: peers refreshed
Jan 6 00:13:21 localhost ntpd[23713]: Listening on routing socket on fd
#22 for interface updates
Jan 6 09:09:31 localhost ntpd[23713]: Attempting to register mDNS
Jan 6 09:09:31 localhost ntpd[23713]: *** WARNING *** The program
'ntpd' uses the Apple Bonjour compatibility layer of Avahi.
Jan 6 09:09:31 localhost ntpd[23713]: *** WARNING *** Please fix your
application to use the native API of Avahi!
Jan 6 09:09:31 localhost ntpd[23713]: *** WARNING *** For more
information see <http://0pointer.de/avahi-compat?s=libdns_sd&e=ntpd>
Jan 6 09:09:31 localhost ntpd[23713]: mDNS service registered.
root@fireball / #
It doesn't show that it is doing anything but the clock is somewhat
accurate but it is still having to adjust it like before. I use ntpdate
to see how far the clock is off. If I run it every few minutes, I can
see it drift further away from the correct time then when ntp syncs, it
resets it again. It did generate the ntp.drift file but it is still not
adjusting the clock like on my other rig.
I also read where the caps USE flag should be enabled. I did but it
doesn't appear to have helped any.
I deleted the /etc/adjtime but it has not been recreated. What creates
this file? I deleted it a couple days ago and nothing has brought it
back yet.
I'm about ready to see what Linux would be like with no freaking clock
at all. lol Now to see what I am going to try next.
Dale
:-) :-)
Francesco Talamona
/sbin/hwclock --systohc does.
What happens in the long run if you don't run any synchronization
service at all? Does the time go stray or it just exhibits a systematic
error?
Ciao
Francesco
--
Linux Version 2.6.36-gentoo-r6, Compiled #2 SMP PREEMPT Mon Jan 3
11:54:58 CET 2011
Two 2.9GHz AMD Athlon 64 Processors, 4GB RAM, 11659 Bogomips Total
aemaeth
kashani
> 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
Neil Bothwick
> Well, I tried openntp for a good while last night and it was worse than
> ntp. It was adjusting the clock by something like 20 seconds at a
> time. Even ntp wasn't that bad.
ntpd won't shift the clock by too much at a time. If your clock is
further out, you should use ntp-client to correct it. Add ntp-client to
the default runlevel to make sure the clock is correct when you boot.
--
Neil Bothwick
This is as bad as it can get; but don't bet on it.
Thanasis
>
> Well, I tried openntp for a good while last night and it was worse
> than ntp. It was adjusting the clock by something like 20 seconds at
> a time.
/etc/conf.d/ntpd:
Jacob Todd
The only thing I have changed with openntp is in /etc/ntpd.conf, I added `listen on *`, maybe a few servers and in /etc/conf.d/ntpd or whatever it's called, I added `-s` to OPTIONS. I've been using that on a server for a year and my laptops for over two. I've had no problems with syncing.
Dale
> On Thursday 06 January 2011, Dale wrote:
>
>> I deleted the /etc/adjtime but it has not been recreated. What
>> creates this file? I deleted it a couple days ago and nothing has
>> brought it back yet.
>>
> /sbin/hwclock --systohc does.
>
> What happens in the long run if you don't run any synchronization
> service at all? Does the time go stray or it just exhibits a systematic
> error?
>
> Ciao
> Francesco
>
I been using hwclock and it did generate adjtime file. So far so good.
I been googling a bit. I ran a command with && and sleep cycles for a
while to let the adjtime file get a good figure. It changed each time.
I'm going to let it run for a while more. I ran that while ntp was
stopped too. I didn't want ntp to get in the way.
I haven't tried long term without ntp running. I did stop the service a
while and it was off a lot in just a little bit. I think I was
unmasking the unstable version and compiling it. Since this is a 4 core
rig, it doesn't take that long. Downloading source, compiling and
installing couldn't take longer than a few minutes plus me editing
config files. I figure it was about 20 minutes or so and it was off a
little less than a minute if I recall correctly. I guess my clock would
be off hugely if left alone for a day or so. Since I don't reboot very
often, I would have my days and nights messed up before long. lol
I'm hoping having a good adjtime file will help some at least. Time
will tell I guess. Pardon that usage of time. ;-)
Dale
:-) :-)
Dale
I have used ntp on another machine for years with no problems. I think
this is deeper than ntp. That's why I am looking for something else. I
don't think it is ntp itself that is the problem. I'm working on
adjtime now. I plan to update the BIOS if that doesn't help. Maybe
they changed something in there. I think there has been 3 or 4 updates
since the version I have.
Dale
:-) :-)
Dale
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
:-) :-)
William Kenworthy
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.
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.
>
>
I should have posted this a while back. Here we go:
root@fireball / # ntpq -p
remote refid st t when poll reach delay offset
jitter
==============================================================================
+triangle.kansas 128.252.19.1 2 u 4 64 127 56.270 673.749
238.194
+B1-66ER.matrix. 192.43.244.18 2 u 14 64 377 75.505 672.846
165.087
+kallisti.us 208.90.144.52 3 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
root@fireball / # ntptrace
localhost: stratum 16, offset 0.000000, synch distance 0.000240
root@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:
root@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_sd&e=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
root@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:
root@fireball / # cat /var/lib/ntp/ntp.drift
500.000
root@fireball / #
This is the adjtime file from a good ways back:
root@fireball / # cat /etc/adjtime
0.000000 1294340368 0.000000
1294340368
UTC
root@fireball / #
And the current one after some updates:
root@fireball / # cat /etc/adjtime
0.000000 1294365381 0.000000
1294365381
UTC
root@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 netselect or
something to find the closest and fastest one to get a accurate clock.
Hoping for ideas. Redoing adjtime doesn't seem to have helped.
Dale
:-) :-)
Paul Colquhoun
> 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:
>
> root@fireball / # ntpq -p
> remote refid st t when poll reach delay offset
> jitter
> ===========================================================================
> 238.194
> +B1-66ER.matrix. 192.43.244.18 2 u 14 64 377 75.505 672.846
> 165.087
> +kallisti.us 208.90.144.52 3 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
> root@fireball / # ntptrace
> localhost: stratum 16, offset 0.000000, synch distance 0.000240
> root@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.
Dale
> 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:
root@smoker / # ntpdate -b -u -q pool.ntp.org
server 72.26.125.125, stratum 2, offset -0.000087, 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
root@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
:-) :-)
William Kenworthy
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
Dale
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
:-) :-)
Dale
> 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
:-) :-)
Peter Humphrey
> Any other ideas?
You could still try chrony.
--
Rgds
Peter. Linux Counter 5290, 1994-04-23.
Dale
> 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
:-) :-)
Michael Orlitzky
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.
Dale
> On Friday 07 January 2011 22:48:27 Dale wrote:
>
>
>> Any other ideas?
>>
> You could still try chrony.
>
>
Success !!!!!! Check this out:
root@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
root@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:
root@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.28000000 nominal_tick=10000
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.00000000 freq_scale=1.00000000
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.28000000 nominal_tick=10000
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.00000000 freq_scale=1.00000000
Jan 8 15:27:07 localhost chronyd[1632]: Selected source 64.6.144.6
root@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?
Peter Humphrey
> 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!
Peter Humphrey
> 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.
Dale
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
:-) :-)
Peter Humphrey
> 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.