Jacques B. wrote: >> With the way the clock drift is happening, it sounds like a time >> zone setting problem. Both Linux and Windows XP will slowly adjust >> the clock to match the NTP server. Now, if the time zone setting is >> wrong, the system will gain/lose time as it runs, until it matches. >> Running the AtomTime95 program under windows would probably make >> things worse by fighting with the NTP program windows is already >> running. Making sure that the time zone is the same under both >> Windows and Linux, making sure it is the correct time zone, and not >> using AtomTime95 should fix the problem. >> >> Mikkel >> -- > I'm confused about this one. I don't see time zone settings being the > issue as that would cause the time to be off by an hour (or two, or > whatever depending on the time zone) not drift by a few minutes to > 100+ minutes over the course of a few hours. And Windows or Linux > would not slowly adjust the clock to match NTP, it synchronizes with > it and changes it to match. What would be the reason for Windows or > Linux slowly changing the time to synch up with NTP? It's not a bad > suggestion to check and make sure that they have the same time zone > settings. But that would not account for clock "drifting". > > Jacques B. > ntpd does not normally make one large change. Instead, it will slowly change the clock over time. This is especially true if the system clock is ahead of the correct time. Turning back the clock can cause interesting problems for any program that uses system time or timestamps. So what is done instead is that the clock is slowed down instead, until the time matches. (I think it skips every nth time tick.) On the other hand, if the difference is too large, ntpd should exit with an error. >From man ntpd: Under ordinarily conditions, ntpd adjusts the clock in small steps so that the timescale is effectively continuous and without discontinuities. Mikkel -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
