Neither the openntpd nor the ntpd.conf manpage have this information.
I have ntpd running on my server. It's all the default settings, except I commented out its ability to be a server to other machines:
# restrict -4 default kod notrap nomodify nopeer noquery
# restrict -6 default kod notrap nomodify nopeer noquery
restrict default ignore
If I run ntpdate -q ntp.ubuntu.com, I'm told that my machine's clock is off by 7 seconds.
What's going on? How can I diagnose what's happening, is there a log I can turn on?
more info #1
# ntpq -np
remote refid st t when poll reach delay offset jitter
==============================================================================
91.189.94.4 193.79.237.14 2 u 30 64 7 108.518 -0.136 0.361
more info #2
Here's what this looked like when I asked the question:
# ntpdate -q ntp.ubuntu.com
server 91.189.94.4, stratum 2, offset 7.191308, delay 0.13310
10 Jan 20:38:09 ntpdate[31055]: step time server 91.189.94.4 offset 7.191308 sec
And here's what it looks like now, after restarting ntpd a couple times (I'm assuming that's what fixed it):
# ntpdate -q ntp.ubuntu.com
server 91.189.94.4, stratum 2, offset 0.000112, delay 0.13164
10 Jan 20:47:03 ntpdate[31419]: adjust time server 91.189.94.4 offset 0.000112 sec
more info #3
I uninstalled ntp and installed openntpd and ran /usr/sbin/ntpd -d, and I'm seeing output like this:
reply from 64.73.32.134: offset 6.715003 delay 0.041152, next query 30s
reply from 208.53.158.34: offset 6.700224 delay 0.036263, next query 31s
adjusting local clock by 6.734120s
reply from 72.18.205.156: offset 6.708575 delay 0.035885, next query 30s
reply from 64.73.32.134: offset 6.701463 delay 0.044199, next query 33s
Which to me pretty clearly indicates that I'm not able to set the time on my server (although, with regular ntp, it does seem to update sometimes...).
more info #4
My VPS provider says:
The latest kernels should not lock your system to our dom0's clock, to be on the safe side you can set xen.independent_wallclock = 1 in your sysctl.conf.
Which I suppose still does not address the issue of the VPS needing a CPU available in order to do correct timing calculations.