Skip to main content

time.windows.com is broken... is your clock off too?

It seems that time.windows.com is broken, reporting unsynchronized time off by two minutes or more. Why is this a big deal? Time.windows.com is the default Network Time Protocol server used by the Windows Time Service in Windows XP, 2003, and Vista systems. So there are literally millions of systems out there without an accurate source of internet time.

I have personally reported the issue to Microsoft, and Akamai as well (they seem to host the actual servers). But there has been no response from either for several days. Reports on the internet indicate that time.windows.com has been broken for at least a week!

Fortunately, it is easy to switch to a different time server. If your computer is part of a Windows domain at your workplace, it will get time from your domain controller by default, so you don't need to do anything. If your system is a domain controller, or is stand-alone, you should run these commands: C:\>w32tm /config /manualpeerlist:"us.pool.ntp.org,0x8" /syncfromflags:MANUAL /update
C:\>w32tm /resync /rediscover


Note these commands do not work on Windows 2000. For that the command would be:
C:\>net time /SETSNTP:us.pool.ntp.org

What is us.pool.ntp.org? It is the United States address for the global NTP Pool Project. You can substitute your own two-letter country code for the "us" portion if you are not in the continental United States. If you're in London, for example, use uk.pool.ntp.org.

The ",0x8" after the time server name tells Windows to use a client-mode association with the time server. This isn't strictly necessary, but the proper way to configure an NTP client talking to an NTP server. If you don't use it, Windows checks the time exactly once per hour, rather than adjusting its time-checking interval automatically based on clock performance and network conditions.

One final note, do not use popular "stratum-1" time servers to synchronize your client. These systems are typically run by national standards laboratories (an example would be time-a.nist.gov). These time servers are quite overloaded, and Windows systems cannot use the increased accuracy they provide anyway (the Windows Time Service is only accurate to about 16ms). The NTP Pool Project was started for the specific purpose of reducing the load on the Internet's stratum-1 time-keepers.

Comments

Mayuresh said…
optionally you can use time.nist.gov with your windows XP 2003 VISTA etc
RPM said…
NIST and other standards-laboratory stratum-1 time servers are heavily loaded. A desktop Windows PC should not connect directly to any stratum-1 time server over the internet, as the high-precsion time cannot be effectively used by Windows (which has a resolution of 16 ms). The precision will be vastly reduced by Internet traffic in any case.
The NTP pool project was started for the very specific purpose of reducing the traffic load on the major public stratum-1 time servers around the world, which are a scarce resource.
In short, do not use a NIST (or USNO, or any other worldwide standards body) time server unless you absolutely must for regulatory reasons.

Popular posts from this blog

Fixing slow NFS performance between VMware and Windows 2008 R2

I've seen hundreds of reports of slow NFS performance between VMware ESX/ESXi and Windows Server 2008 (with or without R2) out there on the internet, mixed in with a few reports of it performing fabulously.
We use the storage on our big Windows file servers periodically for one-off dev/test VMware virutal machines, and have  been struggling with this quite a bit recently. It used to be fast. Now it was very slow, like less than 3 MB/s for a copy of a VMDK. It made no sense.
We chased a lot of ideas. Started with the Windows and WMware logs of course, but nothing significant showed up. The Windows Server performance counters showed low CPU utilization and queue depth, low disk queue depth, less than 1 ms average IO service time, and a paltry 30 Mbps network utilization on bonded GbE links.
So where was the bottleneck? I ran across this Microsoft article about slow NFS performance when user name mapping wasn't set up, but it only seemed to apply to Windows 2003. Surely the patch me…

Google's public NTP servers?

I was struggling with finding a good set of low-ping NTP servers for use as upstream sources in the office. Using pool.ntp.org is great and all, but the rotating DNS entries aren't fabulous for Windows NTP clients (or really any NTP software except the reference ntpd implementation).

ntpd resolves a server hostname to an IP once at startup, and then sticks with that IP forever. Most other NTP clients honor DNS TTLs, and will follow the rotation of addresses returned by pool.ntp.org. This means Windows NTP client using the built-in Windows Time Service will actually be trying to sync to a moving set of target servers when pointed at a pool.ntp.org source. Fine for most client, but not great for servers trying to maintain stable timing for security and logging purposes.

I stumbled across this link referencing Google's ntp servers at hostname time[1-4].google.com. These servers support IPv4 and IPv6, and seem to be anycast just like Google's public DNS servers at 8.8.8.8. time…

Presets versus quality in x264 encoding

I'm scoping a project that will require re-encoding a large training video library into HTML5 and Flash-compatible formats. As of today, this means using H.264-based video for best compatability and quality (although WebM might become an option in a year or two).
The open source x264 is widely considered the state of the art in H.264 encoders. Given the large amount of source video we need to convert as part of the project, finding the optimal trade-off between encoding speed and quality with x264-based encoders (x264 itself, FFmpeg, MEencoder, HandBrake, etc.) is important.
So I created a 720p video comprised of several popular video test sequences concatenated together. All of these sequences are from lossless original sources, so we are not re-compressing the artifacts of another video codec. The sequences are designed to torture video codecs: scenes include splashing water, flames, slow pans, detailed backgrounds and fast motion. I did several two-pass 2500 kbps encodings using …