Skip to main content

time.windows.com fixed

Well, it appears that time.windows.com is now fixed, after a few weeks of serving up invalid time. Presumably, the clocks on millions of Windows machines worldwide are now slowly drifting back into synchronization with the rest of humanity.

I find it rediculous that such a problem could go unnoticed and unfixed by Microsoft for so long, and that it took a Microsoft participant on a programmer's blog reading about it to track down and correct the issue.
U:\>w32tm /monitor /computers:time.windows.com,us.pool.ntp.org
time.windows.com [207.46.130.100]:
NTP: +0.0541156s offset from local clock
RefID: time-nw.nist.gov [131.107.1.10]
us.pool.ntp.org [66.91.129.70]:
NTP: +0.0293621s offset from local clock
RefID: bigben.ucsd.edu [132.239.1.6]

Comments

joeditt said…
It's not just ridiculous, it's impertinent ignorance of users - the monopolistic company's standard policy.

And though MS support service costs an extra fortune, obviously showing the corporation regards itself not the least responsible for the operability of what you already paid for, that service mostly won't help. MS' oh so great generosity then refers you to user forums where you mercifully are free to endlessly plough through uncounted postings most of which an average user can't understand. Though all the knowledge there's due to skilled users who share their experiences with others, sometimes to satisfy their vanity, but mostly thanks to remarkable cooperativeness - in any case receiving no reward for their contributions from regrettably (whimper!) underpaid, needy MS (sob!).

Which is so impecunious that to the very day it is unable to even offer the time synchronization fix to its customers. Comprehensible, as those who might have the means and competence to spread the good news are too busy with other things that must be delivered by the automatic Windows updates, i.e. sensational new templates for MS Words fax and letter documents. No doubt it's clearly the duty of self-exploiting folks like you to publish facts which are conductive to negligibilities like the system software's operational reliability.

So whoever reads this, go donate a few Cents for poor Bill. Hanky, anyone?
Louis said…
Noticed a 4 minute or so lag on my machine running Windows XP. Hit the update now button... it synced, but didn't correct the time. Checked the NIST and Greenwich sites to confirm the lag.

I changed my time server to time.apple.com and it works now.
RPM said…
Louis, time.windows.com looks okay to me at the moment:

U:\>w32tm /monitor /computers:time.windows.com,0.us.pool.ntp.org,1.us.pool.ntp.o
rg
time.windows.com[207.46.197.32:123]:
ICMP: 68ms delay
NTP: -0.0247374s offset from local clock
RefID: (unknown) [0xCE83300A]
Stratum: 3
0.us.pool.ntp.org[209.67.219.106:123]:
ICMP: 121ms delay
NTP: -0.0236769s offset from local clock
RefID: hatch.dayww.net [74.53.198.146]
Stratum: 3
1.us.pool.ntp.org[63.240.161.99:123]:
ICMP: 15ms delay
NTP: -0.0826970s offset from local clock
RefID: time-a.nist.gov [129.6.15.28]
Stratum: 2

This is one of the reasons why the NTP folks at ISC recommened you choose multiple NTP servers, to protect against outages or temporarily incorrect clocks. I suggest everyone configure four separate severs: [0-3].pool.ntp.org. The NTP pool project now has over 1000 servers, and a geographic DNS system to point you to a server in your own country if possible.
Anonymous said…
Anybody look lately? My machine said it sync'd successfully at 11 AM this morning, shows 4:04PM when it's really 6:18PM.
Huh?
RPM said…
@anonymous: I just checked a few minutes ago and it seems to be working fine. The offset is less than 20 miliseconds different than pool.ntp.org.

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 …