When ntpd is in this state, the clock loses roughly half a second every
minute, or about 10 minutes after a day of uptime (!).

I'm not sure if it's relevant, but I first noticed this problem about a
month ago around the time ntp was upgraded from 4.2.0a to 4.2.2p1 (as
part of upgrading from Fedora Core 5 and Fedora Core 6). Prior to that,
the system ran ntpd for years without any issues.

Re: ntpd (4.2.2p1) stays "synchronized to LOCAL"

Jordan Russell wrote:
> When ntpd is in this state, the clock loses roughly half a second every
> minute, or about 10 minutes after a day of uptime (!).

I think I've narrowed down the cause of this: The Linux kernel
(2.6.18.5) is actually misdetecting the CPU frequency; it claims the
processor is running at ~804 MHz when it's really running at ~797 MHz.

I find that ntpd works fine if I switch away from the default "tsc"
clocksource to a clocksource not dependent on the CPU frequency being
detected correctly, e.g. "acpi_pm":

How badly does the clock drift if ntpd is not running? If it's still
ten minutes per day, you either have a severe hardware problem or a
software problem that is causing your system to lose timer interrupts.
>
> I'm not sure if it's relevant, but I first noticed this problem about a
> month ago around the time ntp was upgraded from 4.2.0a to 4.2.2p1 (as
> part of upgrading from Fedora Core 5 and Fedora Core 6). Prior to that,
> the system ran ntpd for years without any issues.

Simplify!!! If you don't NEED IP V6, don't mess with it!!! Even if
you NEED it, debugging should be easier if you can eliminate it temporarily.

At the time you took your ntpq "banner", your clock appears to have been
off by something between sixteen and twenty-five seconds. Worse, two
of your servers have opinions of what time it is that differ by about
ten seconds; one or both are insane!!!

Can you add at least one more internet server? Two more would be
better. A total of five servers allows you to reject two bad ones and
still have a workable configuration.

I suspect that your O/S upgrade introduced some bugs. It's hard to
tell, from here, what or where they might be. Both the O/S and the new
version of ntpd are suspect at this point.

Another odd thing is that your poll interval seems locked at 1024
seconds when, given the humongous offset, I'd expect to see polling at
64 second intervals. With a polling interval that large, it may take
weeks to synchronize your clock. Normally we expect to see 1024 second
polling only when your clock is already very well synchronized.

You can eliminate the RedHat version of ntpd by downloading the source
using the links at http://www.ntp.org/, and building from source. If
that works, your problem is solved. If it doesn't work, I'd say that
you have either an O/S problem or a hardware problem.

The poll interval is 64 seconds. ntpd sets the poll intervals of
rejected sources to maxpoll. They are being rejected because the jitter
appears too high, which is a result of the high time slew rate (frequency
error) causing different samples to vary greatly in offset.

This also raises the question of why the local clock was configured
in the first place. If it had not been, ntpd would have correctly
detected that it was in a hopeless situation and would have reported
unsynchronised and eventually shut down. In my view, most people shouldn't
configure the local clock, and those that do should have thought carefully
about it.

Re: ntpd (4.2.2p1) stays "synchronized to LOCAL"

david@djwhome.demon.co.uk (David Woolley) writes:
> In article ,
> This also raises the question of why the local clock was configured
> in the first place. If it had not been, ntpd would have correctly
> detected that it was in a hopeless situation and would have reported
> unsynchronised and eventually shut down. In my view, most people shouldn't
> configure the local clock, and those that do should have thought carefully
> about it.

Under what circumstances *should* the local clock be configured?

(Your remark hit a nerve. I recently booted my laptop without network
access for the first time, and ntp wrote 0.0 into the driftfile. Sounds
like it wouldn't have done that if the local clock hadn't been
configured.)

Jon

Re: ntpd (4.2.2p1) stays "synchronized to LOCAL"

"Jon KÃ¥re Hellan" wrote in message
news:1mslfuprbu.fsf@persaunet.uninett.no...
[...]
> Under what circumstances *should* the local clock be configured?

Canonically, 'when it is being disciplined by other means'.

In practice, when you want your bottleneck host to keep serving time
even when its Internet connection has (temporarily) failed. That way,
the entire flock stays with it, which is probably preferable to all
of them drifting every which way. The expected variation is halved
immediately; also, an always-on Internet gateway will probably coast
closer to real time than a herd of laptops.

Groetjes,
Maarten Wiltink

Re: ntpd (4.2.2p1) stays "synchronized to LOCAL"

"Jon Kåre Hellan" wrote
>
> Under what circumstances *should* the local clock be configured?
>
Usually, the local clock is configured on a server only in the case when
such a server should provide its service to a LAN even if all the
connections to its upstream servers are lost.

Karel Sandler

Re: ntpd (4.2.2p1) stays "synchronized to LOCAL"

Jon Kåre Hellan wrote:
> david@djwhome.demon.co.uk (David Woolley) writes:
>
>
>>In article ,
>>This also raises the question of why the local clock was configured
>>in the first place. If it had not been, ntpd would have correctly
>>detected that it was in a hopeless situation and would have reported
>>unsynchronised and eventually shut down. In my view, most people shouldn't
>>configure the local clock, and those that do should have thought carefully
>>about it.
>
>
> Under what circumstances *should* the local clock be configured?
>

Normally the local clock is configured only when the system is serving
time to other systems and must continue to do so even if it loses its
connection to its upstream servers.

It is definitely a clock of last resort; if it were any good at all, why
would you bother running ntpd??? If ntpd had the clock synchronized
you have anywhere from a few minutes to a few hours of "holdover" during
which the time is still close to being correct. In most cases a few
very definitely means VERY few. If the temperature is tightly
controlled, clock drift should be minimal, if not, the clock will start
drifting as soon as the temperature changes.

A lot of people seem to want to use the local clock to synchronize
clocks in an isolated network. This can be made to work if you don't
really care about having the correct time and don't need really tight
synchronization.

Re: ntpd (4.2.2p1) stays "synchronized to LOCAL"

We're experiencing exactly the same thing with 4.2.0. We recently
migrated some servers to SLES10, and since we can't get NTP working
anymore. No syncing to any outside source. I'd be highly interested if
you find a solution

Re: ntpd (4.2.2p1) stays "synchronized to LOCAL"

"Richard B. Gilbert" wrote in message
news:ILmdnVqD-5g_EOjYnZ2dnUVZ_q-dnZ2d@comcast.com...
[...]
> It is definitely a clock of last resort; if it were any good at all,
> why would you bother running ntpd???

Isn't it obvious? To find out what goes into ntp.drift. (-:
With the first-order error out of the way, it isn't so bad.

> [...] If the temperature is tightly controlled, clock drift should
> be minimal, if not, the clock will start drifting as soon as the
> temperature changes.

I find my attic is a very constant environment. The stack of desktop
cases, with the gateway in the middle, certainly helps to keep its
temperature up.

Re: ntpd (4.2.2p1) stays "synchronized to LOCAL"

Re: ntpd (4.2.2p1) stays "synchronized to LOCAL"

Richard B. Gilbert wrote:
> How badly does the clock drift if ntpd is not running? If it's still
> ten minutes per day, you either have a severe hardware problem or a
> software problem that is causing your system to lose timer interrupts.

Thanks for responding.

Yes, it turns out the problem had nothing to do with ntpd after all. It
seems that starting in Linux 2.6.18, the CPU's time stamp counter (TSC)
is used to keep time. In my case, for some unknown reason, the kernel
sometimes misdetects the CPU's TSC frequency on boot, resulting in
severe clock drift that ntpd is unable to correct.

In case anyone else is afflicted by the same problem, I've managed to
work around it by adding the following parameter to my kernel command
line in grub.conf:

clocksource=acpi_pm

This tells the kernel to use the ACPI PM timer to keep time instead of
the CPU's TSC. (From what I understand, the ACPI PM timer is what older
Linux kernels used by default.)

--
Jordan Russell

Re: ntpd (4.2.2p1) stays "synchronized to LOCAL"

Stefan wrote:
> We're experiencing exactly the same thing with 4.2.0. We recently
> migrated some servers to SLES10, and since we can't get NTP working
> anymore. No syncing to any outside source. I'd be highly interested if
> you find a solution

I solved my problem by adding "clocksource=acpi_pm" to the kernel's
command line (see other post).

Note, however, that the "clocksource" parameter only exists starting in
Linux 2.6.18. It looks like older versions had a "clock" parameter that
performed a similar function.

--
Jordan Russell

Re: ntpd (4.2.2p1) stays "synchronized to LOCAL"

It would be Real Helpful if you would add appropriate information about your
situation to: