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

Presets versus quality in x264 encoding

Google's public NTP servers?