On Sep 26, 12:11 pm, Evandro Menezes <[EMAIL PROTECTED]> wrote: > The fact remains that W32TIME is doing a "better" (your definition may > vary) job than NTP to keep my system time in "lock-step" (your > definition may vary) with a reference.
I think I found out why NTP couldn't manage. I figured that as it was stepping every 20min by 0.45s, approximately, it would be the equivalent of an error of roughly 350PPM, or well within the capabilities of NTP. So I checked out the contents of the drift file: 450PPM. In other words, NTP was over compensating! I deleted the drift file and fired up NTP after stopping W32TIME. It's now keeping the time in sync pretty well: http://img218.imageshack.us/img218/3609/peerstatscf6.png (never mind the spike, when the system lost network connection). The only reason I can think of how NTP got such a huge drift was during installation. Although the package states that its stopping W32TIME, somehow it didn't, as I noticed a few hours later. A short time, yet it seems to have done damage enough. Thanks. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
