Why is my NTP controlled computer clock two minutes ahead?

Question

The clock in my computer is configured to be synchronized using NTP. To verify this I have tried two NTP clients using various NTP servers. My computer and the NTP clients are in complete agreement about the current time even across a wide range of NTP servers.

I also have a GPS and my national phone company provides an accurate clock available by calling a specific phone number. Both my GPS and the phone company agrees on the current time. However, my computer is almost precisely two minutes (or 1 minute and 59 seconds) ahead of what I believe to be the "real" current time where I live.

Why is my computer two minutes ahead? I realize that synchronizing clocks using the internet may not be entirely accurate as there is latency, but two minutes is a very long time on the internet. Is NTP really two minutes ahead? I'm running Windows 7 and live in the time zone UTC+1, but I don't think that is important in understanding my problem.

Solution 1

Unfortunately I made some mistakes when I posted my question. I wanted to bypass the NTP service of my computer to provide an independent source of internet time information and used two simple utilities for that. I believed these utilities were getting time information from the internet using NTP when they in fact were displaying the (wrong) local time on my computer.

In my initial question is was rather vague about how NTP was used by my computer. It is part of a Active Directory domain and time is synchronized from the domain controller. I had verified that the configuration was OK, but I had overlooked a small detail.

Solution

The domain controller was running in a Hyper-V virtual machine. The Windows time service on the domain controller was configured properly to use NTP, but the Hyper-V virtual machine had all intergration services enabled including time synchronization. This setting will always keep the time on the virtual machine synchronized with the Hyper-V host even if you set the clock manually or through NTP.

The solution was simply to disable that particular integration service in the Hyper-V manager for the domain controller virtual machine. Restarting the Windows time service immediately corrected the time on the domain controller and subsequently on my computer.

Solution 2

GPS time isn't the same as UTC, it's just very close.

GPS is a very accurate source as far as time differences go, but as it doesn't take into account leap seconds it hasn't actually been in sync with UTC since January 1980. However it's only about 15 seconds ahead, so that doesn't account for your 2 minute difference.

If your other time sources are based on the international atomic clock standard (TAI, Temps Atomique International), then they're also not set to UTC, not because they're inaccurate, but more because UTC is inaccurate in comparison. They don't take into account leap seconds, and their time is based on ticks of the SI standard 'second' rather than being based on the rotation/orbit of the Earth as UTC is. They're about 34 seconds ahead of UTC. Still doesn't account for your difference.

See here http://leapsecond.com/java/gpsclock.htm or here http://en.wikipedia.org/wiki/Global_Positioning_System#Timekeeping for more info.

Solution 3

If you disable NTP, set your computer's clock wrong by several minutes (perhaps 2 minutes slow instead of 2 minutes ahead), and then re-enable NTP, does it stay 2 minutes slow, or go back to 2 minutes ahead?

I ask because I've seen NTP software silently fail before, so although it looked like the NTP software was enabled, and even though I had packet traces showing the NTP queries going out to the server and the responses coming back in, my system clock still wasn't getting set to what the time server was saying.

It would be interesting to see packet traces showing your NTP lookups. For example a tcpdump of "port 123" with the "-v" and "-s0" options set should show what you need to know.

Solution 4

It's also important to remember that many NTP clients will refuse to change the clock by large amounts; if the times are so discrepant, then there's a good chance at least one of them is wildly wrong and needs human intervention.

View more solutions

Comments

[quack quixote]

so, you believe your GPS & phone are "real time", but your computer is "off by 2 minutes"? i'd be tempted to make the opposite conclusion.

[pmms]

My GPS is getting information from the satelites and I assume that the information is very accurate. The phone service IS very accurate and can be considered a sort of "national" clock. I realize that there may be some latency while using a phone, but two minutes latency would make conversations impossible.

[Peter Mortensen]

I agree with Martin Liversage. The phone service has been used to time astronomical events for at least 20 years. E.g. lunar occultations, en.wikipedia.org/wiki/Occultation#Occultations_by_the_Moon, or asteroid occultations, en.wikipedia.org/wiki/Asteroid_occultation

[Zoredache]

What time service are you using, the built in windows time service or something else?

[quack quixote]

virtual machines generally cannot keep time correctly, which is why they provide host-sync services. the better solution is to correctly configure the NTP service on the virtual domain controller's host OS and leave the host-guest-time-sync enabled.

[ardavey]

As your solution doesn't match up with any of the answers, I would suggest adding it as an answer to your question and then accepting it as the correct one. Answering your own questions is encouraged--especially on a useful question such as this.

[pmms]

@Emory Bell: I will do as you suggest.

[GAThrawn]

Was going to add this as a comment, rather than an answer as it doesn't really answer your main problem, but it got a bit long for the comment system

[pmms]

When I get some more time I will do some further analysis. Initialy I believed that the problem was with NTP on my local network, but I have used two NTP clients that doesn't affect my computer clock, but simply displays the time from an NTP server, and those two clients display exactly the same time as the time on my computer. It could be an issue about converting the time to local time, but why would that add two minutes? I will investigate further using some of your ideas.

[Spiff]

GAThrawn, that Wikipedia article/section you linked to lead me to believe that most GPS receivers know the difference between GPS time and UTC, and display UTC. User confidence would be severely undermined if GPS receiver's clock was "constantly off by 15 seconds" (as the average user might perceive the situation).

[GAThrawn]

@Spiff true, consumer GPS units know the time difference to apply before displaying to the user, I'd imagine they do this at the same time as applying any time zone differences. But it's something that unit has to be programmed to do by the manufacturer, it doesn't come as part of the GPS spec. I can imagine scenarios where units not specifically targeted at consumers would display the actual GPS time, rather than a corrected one.