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

:-) :-)

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.

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

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

:-) :-)

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 <billk@iinet.net.au>
Home in Perth!

Try the following and see if it resets time correctly

date 0101010101 && /etc/init.d/ntpd restart && date

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"

I think you should prefer openntpd over ntpd, because I think openntpd
is developed by openbsd, which means more secure ...

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

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
--
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