[ntp:questions] Re: ntpd local synchronization fails?

Wilhelm Greiner wilhelm.greiner at web.de
Tue Nov 15 10:21:01 UTC 2005

* Danny Mayer <mayer at ntp.isc.org> schrieb:
>  Wilhelm Greiner wrote:

> > i have an ntp multicast Client running, but it fails
> > to synchronize his local clock, ntp as Service is
> > running and delivering the right time. Only the
> > local clock will not be set.
> > NTP Version 4.1.2 is running on Linux 2.6.12.
> > I cant use ntpd Version 4.2.x, there is a multicast
> > Client bug.

>  Not any more. Please upgrade to the latest ntp-dev snapshot. The fix
>  should be in there.
Great! I try this.
The Problem is that there are any ntpd installations out now, i will
try to check if there is another possible config Option or so first.

It is not realy easy to roll out new binaries.

> > It seems that the step is to big and the kernel fails, is that true?

>  If the step is too big and you didn't start ntpd with the -g flag, ntpd
>  will exit.

Thats clear, my startscript adds -g, in my tests i set the time to
10 minutes in the future, i was looking that it alway be under 1000 s.

> > What can i do to force ntpd let the local clock synchronized?

>  You don't synchronized to LOCAL, since that is by definition the same as
>  the local clock.

OK, but it dont set the time, i stopped ntpd, set time 10 minutes to the
future and restart ntpd, _it doesnt_, also after a day, set the time.

When i look via date, the time stay in the future (600 sec round about).

In the syslog File i search for Entries like "time set -0.042078 s"
but i only found "time set 0.000000 s\nsynchronisation lost" in
the messages log.

After "nsynchronisation lost" nothing more appear.

> > [root at ntp log]# ntpq -p
> >      remote           refid      st t when poll reach   delay   offset  jitter
> > ==============================================================================
> >  LOCAL(0)        LOCAL(0)         6 l   50   64  377    0.000    0.000   0.015
> > *    2 m    2   64  377    0.015  -21.714  16.686
> > 
>  192.168.1.* is not a valid multicast address. You can only use valid
>  multicast addresses, though the system seems to be accepting it for
>  reasons that I cannot easily tell. Use a valid multicast address. For
>  IPv4 valid multicast addresses are in the range to or should be valid...

> That's what you need to use. Don't use Local unless you
>  are serving other systems from this one, it is unlikely to do what you
>  might think.

I have the local statement in the config for the reason that the multicast
link is broken for a while or so.

The ntpd acts as an Server and should keep serving when the multicast
Link is down or so.

The full config is:

# Multicast Addresse

# lokale Hardware Uhr als Fallback
fudge stratum 6

# Pakete sind verzoegert unterwegs
broadcastdelay 0.350

# Authentifizierungs Schluessel
trustedkey 1
keys /etc/ntp/keys

>  Danny

mfg Wilhelm

More information about the questions mailing list