Jacques Henry wrote:

I am using a System based on FreeBSD 6.3.
On this System an automatically generated ntpd.conf file is generated in
order to synchronize the System clock with a NTP Server. I want to use a
Windows 2003 or 2008 Server to act as the NTP Server. On the Windows System
the NTP Server (Windows Time Service) is *correctly* running. The thing is
that even if there are NTP traffic between the client and the Server (NTP
Client and Server IP packet), My FreeBSD is not synchronizing at all:

freebsd-client>ntpq -p
     remote           refid      st t when poll reach   delay   offset
 NTP_server     2 u  103 1024    1    1.037  -587367

As you can see the offset is huge and never decreases as in a normal way...

My ntpd.conf file looks like:
# File is automatically generated
# Do not edit
tinker panic 1
tinker step  1

My man page for ntp.conf clearly states in regards to the tinker command:

The default values of these variables have been carefully optimized for a wide range of network speeds and reliability expectations. In general, they interact in intricate ways that are hard to predict and some combinations can result in some very nasty behavior.
Very rarely is it necessary to change the default values; but,
some folks cannot resist twisting the knobs anyway and this com-
mand is for them.  Emphasis added: twisters are on their own and
can expect no help from the support group.

so the very first thing you might want to try is to comment out the tinker commands, in particular the panic one. I'm not sure that after you set the panic threshold to 1 second you should expect your ntpd to pay any attention to servers with an offset of 587 seconds. If that fails, consider setting


in your /etc/rc.conf and simply stepping to the correct time at boot time.

In short, I don't think this has anything with a Windows server being involved, and everything to do with starting off almost 10 minutes off and a config file that says to never make a step correction larger than 1 second and to panic if you see an offset of over 1 second.


--Jon Radel

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to