NTP problem, Client will not accociate with server

[paul vail_1]

Hi all,

I have a problem with an NTP client being unable to accociate with a an NTP server. I am able to run ntpdate and it syncs the time correctly, i then start xntpd i get the following

fmdbln95:root /sbin/init.d > ntpq -p
remote refid st t when poll reach delay offset disp
===============================================
itbkln99.qadev. ntp002-cer01-25 6 u 39 64 7 -0.18 -69093. 15882.8

For some reason the Client does not accociate with the server... i have also discovered that the system clock is faulty and it is running fast, could this impact the NTP functionality?

the only entries i have in the ntp.conf are the server name and authenticate set to no.

I have other clients which appear to be configured in exactly the same way (connecting to same NTP server on same DNS domain) which work correctly. anybody have any ideas??

[john kingsley]

Check:
/etc/rc.config.d/netdaemons

The following variables should be set:
export NTPDATE_SERVER=
export XNTPD=1
export XNTPD_ARGS=

[Bill Thorsteinson]

Is ntp running:
ps -ef | grep ntp

Check the peers list
ntpq -c peers

Consider enabling peers stats in /etc/ntp.conf
uncomment and set statsdir line
uncomment peerstats line.
Restart xntp and run tail -f on the peerstats
file. Should initially have one line every 16 seconds.

[paul vail_1]

My netdaemons is set to the following

/etc/rc.config.d/netdaemons

export NTPDATE_SERVER=itbkln99
export XNTPD=1
export XNTPD_ARGS=

[paul vail_1]

I have tried enabling peerstats but get no output.

ntpq -c peers produces the same output as above.

[Thomas Bianco]

the NTP deamon requires a very small offset in time inorder to associate, consider running
ntpdate -d
to ensure times are close before starting the NTP deamon.

also, your ntp.conf file should look something like this:

driftfile /var/log/ntp.drift
logfile /var/log/ntp.log
server sometimeserver.somedomain.net

really, server is the only critical option, but logfile and driftfile will give you some clues and let the ntp deamon corret the clock skew, respectively.

[rick jones]

Indeed, as pointed-out if the client clock is "too far" off of the server clock, NTP throws-up its hands and cries for help - that cry for help can be found in the /var/adm/syslog/syslog.log file. I'm not sure if ntpdate may have a similar, albeit larger limit.

Also, if I'm interpreting the ntpq output correctly, you don't have very good connectivity to the server.

If the client clock is too fubar, the ntpd may not be able to keep it in check, in which case the only recourse would be to more fully investigate the cause of the clock fault.

[Steven E. Protter]

firewalls commonly block ntp protocol?

Windows time servers frequently can't meet the standard for Unix.

You may need to get different software for windows from ntp.org.

SEP

[rick jones]

firewalls could be involved I suppose, but I would have expected that to be an all or nothing proposition, and it is clear that _some_ traffic is being exchanged between the NTP client and server.

of course, another thing... there really should be at least _two_ servers configured in the config file - relying on just one time server isn't a good idea...

[Bill Thorsteinson · Accepted solution]

Sorry I realy should have read your output.
You grabbed it fairly early in the cycle.
Give it about 10 minutes to syncronize.

Reach should be 377 once it has enough data
to syncronize. This is a bit flag of the success of the last 8 requests 0 = no reply,
1 = reply received. It resets to 0 if ntp
jumps the clock (time is off by more than
128 ms). You may be close enough to jump the
clock.

You are showing an offset of 69 seconds
(over a minute) which is extemely high.
What worries me is the disp value of 15 seconds. Even on a really bad connection
this should be much lower 15 seconds.

Try
/sbin/init.d/xntpd stop
/sbin/init.d/nxtpd start
This should give you a message telling you
the clock is being set to the correct time.

Try ntpq -c peers itbkln99
this should have low offset and displ values
at most about 100. If not you have found
your problem.
Try ntpq -n -c peers itbkin99
then set if you can do
ntpq -n -c peers (ip of itbkin99's server)
If it work and is stable add it to your
server list.

Try running
while sleep 60; do ntqp -p; done
and watch the output for a while.
The values for offset and disp should
decease over time. If they increase and
decrase a lot then itbkin99 is likely not
a good ntpserver. I have seen problems
where an ntpserver appeared to be truncating
the time to the second. Your
variances look like itbkin99 or its server
is truncating to the minute.

[Bill Thorsteinson]

You may want to try using your DNS servers,
routers, and/or firewall (inside address).
Try using
/sbin/ntpdate -q (ip of )
If this gives you a good value consider using
it.
using ntpq -c peers may allow you
to trace up the tree to better servers.
Consider using three low stratum servers.

[paul vail_1]

Thanks for your help all, I have reported the error to HP who have recommended replacing the system clock which unfortunately means a full system board replacement.
Ive found that the system clock is running 70% faster than it should be, it looks as if by the time the client trys to sync to the NTP server the drift is too far out for it to resync itself to the NTP server.

[Steven E. Protter]

shalom Paul,

ntp is supposed to override the system clock.

In this situation with the clock really out of whack it might be going out of synch faster than ntp can bring it into sync.

What ntp does if a system is running fast is run the system time slower than reality until the system is in synch with the time source. If the system is going against that this could be why ntp didn't do the trick.

Good Luck,

SEP

[Bill Hassell]

Your clock will never be accurate. Unless your clock is drifting HUNDREDS of seconds per day, there is no reason to replace the system board. You MUST run ntpdate to set the clock for the first time. This is done automatically when you bootup if you followed the instructions above for editing the netdaemons file, then this will occur automatically. xntpd will run once every 64 seconds and begin adjusting the time. NOTE: DO NOT use just one NTP server. There are hundreds of free Internet NTP servers so add another 3-5 servers into your ntp.conf file.

But before you make all this auomatic, you must verify connectivity. Make sure xntpd is stopped first. Then run ntpq -p for each NTP server. If none reply, you may have port 123 blocked in your company so you cannot reach the Internet. That needs to be fixed. Keep testing until you have at least 3 NTP servers responding to ntpq -p

The next step (after ntpq -p tests) is to start xntpd using the startup script:

/sbin/init.d/xntpd start

Let this run for about an hour while checking /var/adm/syslog/syslog.log for aqny errors. Now run ntpq -p and it will report on the quality of the NTP server connections. The REACH value should be close to 377. Now with that one connection you already have, the 15 second delay looks like a very slow (simple modem?) connection. If this is all you have, then monitor the ntpq -p results to see if dispersion and reach are improving with time. If not, you will have to get a GPS clock to site on your network as the NTP server. This will at least get you a reliable NTP source without changing your Internet connection.

For a list of NTP sources, go to www.ntp.org

[Thomas Bianco]

if the clock is 70% off, that means it's counting 60,000 extra seconds a day, more then enough to mess with NTP.

that being said, an authoritative time server should be able to slew the clock back into alignment, provided it's close and stable.

set up a local server on a good clock and set the minpoll and maxpoll directives to very low numbers (i.e. sync frequently) and call it a prefered truechimer. all this is per http://www.eecis.udel.edu/~mills/ntp/html/confopt.html

here's an example ntp.conf:
driftfile /var/ntp/drift
logfile /var/ntp/log
server ntp.local.net minpoll 4 maxpoll 6 prefer true

[paul vail_1]

I have tried to associate with other NTP sources and get the same result.

When i run ntpq associations it reports that the NTP servers are insane, this i gather is why they will not associate and sync.

[Thomas Bianco]

that's the point of the TRUE directive, it forces the server to survive the selection process.

MAXPOLL and MINPOLL force it to synchronize often, which will speed the renormalization of the system clock.

[rick jones]

paul - any word on replacement of the system board, or has it been determined that NTP is supposed to be able to deal with a clock that runs as far off as yours?

despite the attempts to sync with other servers failing, probably best to keep them in the config file so you have more than one configured for when you do get the system board replaced.