[ntp:questions] Windows won't settle
david at rushtone.com
Mon Apr 17 16:50:18 UTC 2006
I've been trying to get both of my Windows XP SP2 machines to sync with
W32Time / w32tm, without luck.
I've been using w32tm /stripchart /computer:us.pool.ntp.org /period:300
to monitor my systems' time.
These two machines are not in a domain, and sit behind my LinkSys
router, which goes to my cable modem to a commercial ISP.
I've mucked with what NTP server I use, as well as the
SpecialPollInterval and UpdateInterval, without finding any satisfactory
On machine 1, I've got TimeProviders\NtpClient\SpecialPollInterval set
to 86,400 seconds (one day), and NtpClient\UpdateInterval at 30 right
now. I'm using us.pool.ntp.org to sync to. Using Ethereal I see
traffic both ways between my machines and hosts in the pool.
Watching the stripchart on machine 1, I see the time slowly drift away
from the "correct" time. Looks like the last time it made an abrupt
correction was around 15:44 yesterday. Since then my system time has
drifted to about +9 seconds (over a period of about 20 hours).
I keep seeing the same pattern, where my click drifts away until the
next SpecialPollInterval, where the clock gets slammed back to
"correct", then slowly drifts away again. I've seen patterns where it
drifts - over one SpecialPollInterval, then drifts + on the next, then -
on the next, and so on back and forth.
I had the same problems even before I played with any of the w32time
parameters. There have been brief (a few hours?) periods when one of
the machines seemed to sync and stay correct, but it would sooner or
later fall back to its old tricks if drifting one way and/or the other.
On my 2nd machine (with similar settings as machine 1), the clock drifts
much more quickly, but seems to settle at about 123 seconds (sometimes
+, sometimes -) from "correct", and sit there until the next
SpecialPollInterval, where it gets slammed back to "correct", or
thereabouts, afterwhich it drifts out to + or - 123 seconds.
I've got a FreeBSD box on the same network, also using us.pool.ntp.org,
and it works just fine (within my ability to hit return on a "date"
command and compare it to one of my consumer-grade radio (WWVB,
presumably) clocks, anyway.
More information about the questions