Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Edit

I've tried all your suggestions, but it seems that ntpd just refuse to synchronize to the server.

[vivs@peter-centos ~]$ /usr/sbin/ntpq -np
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================
 192.168.0.30    .LOCL.           1 u   11   64    3    0.984  232732. 20083.2

Does this jitter "20083.2" indicates the time is manually changed?

I've turned off vmware's time synchronization.

Original Question

Here is the status of ntp

[root@peter-centos gw]# /usr/sbin/ntpq -pn
 remote           refid      st t when poll reach   delay   offset  jitter
=============================================
 192.168.0.30    .LOCL.           1 u  153 1024  377    0.950  1905553 274023.
*127.127.1.0     .LOCL.          10 l    9   64  377    0.000    0.000   0.001

You can see that it only synchronize to '127.127.1.0' which is the local clock.

Is it because of the offset it too large?

But after I manually set the date by date command, it still refuse to synchronize to 192.168.0.30

This is may ntp.conf

# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

# Permit all access over the loopback interface.  This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1
restrict -6 ::1

# Hosts on local network are less restricted.
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
#server 0.centos.pool.ntp.org
#server 1.centos.pool.ntp.org
#server 2.centos.pool.ntp.org
server 192.168.0.30 #blf
#broadcast 192.168.1.255 key 42         # broadcast server
#broadcastclient                        # broadcast client
#broadcast 224.0.1.1 key 42             # multicast server
#multicastclient 224.0.1.1              # multicast client
#manycastserver 239.255.254.254         # manycast server
#manycastclient 239.255.254.254 key 42  # manycast client

# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
#server 127.127.1.0     # local clock
#fudge  127.127.1.0 stratum 10

# Drift file.  Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
driftfile /var/lib/ntp/drift

# Key file containing the keys and key identifiers used when operating
# with symmetric key cryptography.
keys /etc/ntp/keys

# Specify the key identifiers which are trusted.
#trustedkey 4 8 42

# Specify the key identifier to use with the ntpdc utility.
#requestkey 8

# Specify the key identifier to use with the ntpq utility.
#controlkey 8
lkey 8
h the ntpdc utility.
#requestkey 8

# Specify the key identifier to use with the ntpq utility.
#controlkey 8
lkey 8
olkey 8
lkey 8
share|improve this question

migrated from stackoverflow.com Dec 18 '09 at 10:44

This question came from our site for professional and enthusiast programmers.

    
My machine is installed in vmware workstation. So, form all the answers, I guess maybe the jitter becomes so large is because that vmware adjust the time. I will see if I am right. –  ablmf Dec 21 '09 at 6:06
add comment

4 Answers

up vote 7 down vote accepted

Ah -- now it becomes clear:

My machine is installed in vmware workstation. So, form all the answers, I guess maybe the jitter becomes so large is because that vmware adjust the time. I will see if I am right.

Don't run ntp in a VM. The host computer doesn't guarantee CPU slices, so the VM's clock isn't accurate. As you see, ntp is trying to keep up with what looks to it like a wildly varying external clock and eventually gives up.

The general answer to this problem is to not run ntp, to install the VMware tools and lock the VM's clock to the host's clock.

The specific answer depends on the version of Linux you are running. I have some notes on CentOS (probably generally applicable to other RedHat family distributions) here.

share|improve this answer
    
There is also a walk around here : wiki.centos.org/TipsAndTricks/VMWare_Server I've tired, it works! –  ablmf Dec 22 '09 at 2:23
add comment

First off, stop ntpd, and try to set the date using ntpdate {server}:

/etc/init.d/ntp stop
/usr/sbin/ntpdate 192.168.0.30

Does this set your time correctly? Or does it time out?

If it times out, try another NTP server:

/usr/sbin/ntpdate pool.ntp.org

From the high jitter, I would expect the ntpdate to work - once it has, reboot if possible (just restart ntpd if you can't reboot - though many services will get confused by such a time jump), and check ntpq -p again.

share|improve this answer
    
From all the answers. It seems that I should use 'ntpdate' to change date time when ntpd is not running. I tired and I found I could update to 192.168.0.30 by ntpdate. BUT, after I started ntpd again, I saw that ntpd is still not synchronize to 192.168.0.30. I've also removed the local clock from ntp.conf. From ntpq -p, I can see that the jitter is quite large. But I am sure I didn't change the date manual when ntpd is running. –  ablmf Dec 21 '09 at 6:03
add comment

That's a really large jitter value (274023). That indicates that you may have tried to change the time manually while ntpd was running. What you should do is stop ntpd, set the time to the correct time, and then restart ntpd.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.