w32tm /config /localclockdispersion:0
w32tm /config /update

The result is now your rootdispersion is basically 0 + actual from CMOS clock, or well below 1 sec. As such other NTP peers will sync OK instead of giving the rejecting with the “flash=400 peer_dist” error.

http://manpages.ubuntu.com/manpages/lucid/man1/msntp.1.html

To slave my clock, I’ll be playing with a loop something like:

while :
do
# step-sync at bootup and before samba starts
msntp -r –P no $DC
# now run in adjtime mode forever
msntp -a -x $DC
# if msntp quits, we are either shutting down
# or something horrid happened so step-sync and try again
done

I researched a bit more after seeing this:

syslog.0:Nov 9 06:25:01 vmware04 kernel: rtc: lost some interrupts at 512Hz.

Apparently timing on guest os’s is complicated and I shouldn’t be installing ntp. Oh well. I noticed the difference between the two host boxes was the lack of a 64bit kernel on the one not working correctly. I also noticed weird networking issues on it like double outbound packets, but I’m going to pretend that was a dream. There are bits out there on fixing this by hand, but the new amd64 kernel (linux-image-2.6.18-5-amd64) works whereas the other one (linux-image-2.6.18-4-686) didn’t.

On the new host kernel, ntp on the guest os has reasonable jitter and seems to be working right. (i still see weird network stuff, still pretending it doesn’t exist).

Later I’ll worry about not running ntp.

I’m getting “400 peer_dist” in ‘ntpq’ ‘rv’ but I’m not sure it’s related even after chatting in #ntp on freenode about it for a bit.

Rootdispersion seems to hang aroubnd 3000-7000, and when it comes down below 100 it’s alright. I’m currently assuming this is the cause of the peer (the DC) being rejected by ntp. I’ve run:

w32tm /config /manualpeerlist:”0.us.pool.ntp.org 1.us.pool.ntp.org”

On the box. I can’t find a better way to monitor ntp on server 2003 besides w32tm /monitor, which has no information compared to ntpq/ntpdc which has too much information that isn’t explained. I’m hoping it will act ntpish and sync with more servers, bringing down the rootdispersion, thus being more friendly. This is kind of moot as the PDC is working still, but I’m wary at this point that latency fluctuations will too regularly make both the DC and the PDC unusable time sources as far as ntp is concerned.

the flash variable in ‘rv’ in ‘ntpq’ (showpeer in ntpdc brings a numeric equivalent) comes up “00 ok” on the sys.peer (PDC), and “800 peer_loop” on the reject (DC). I’ve checked the refid (‘peers’ in ‘ntpq’) as synch loop is supposed to be when two peers are syncing off each other. I may point this DC out at pool.ntp.org as well and see how that goes. This is getting messy.

I did pull dispersion down to 5 using the command in the post on the PDC role carrying DC, but yeah. I’m not sure it matters.

running:
w32tm /config /reliable:yes
w32tm /config /update

on a a DC that did not have the PDC role was enough to make it it come up as a “candidate” instead of “reject” in the ntpq “associations” command. I double checked the registry and HKLM\System\CurrentControlSet\Services\W32Time\Parameters\Type was still set to NT5DS where as the other changes on the PDC switched this to NTP.

Which is good, as I don’t want to make/manage a Microsoft Time Server system. I just want to get a couple boxes without access to the internet through the firewall to maintain the correct times.