Network-focused analysis of the Windows Time Service
Due to some recent posts on the comp.protocols.time.ntp newsgroup, I took it upon myself to investigate the behavior of the Windows Time Service a bit further using the Wireshark protocol analyzer.
It appears that in Windows XP, 2003, and Vista, the Windows Time Service (w32time) will by default always try to form a “symmetric active” association with configured NTP servers. This can be problematic with some time servers, violates the published RFC-1305 specification, and is not necessary. I could find no explanation on Microsoft’s site for this behavior; I suspect it has something to do with interoperability with older Windows 2000 domain controllers that had very broken NTP.
However, there is a simple workaround. You can simply add “,0x8” to the end of any configured time server, and Windows will only use a client-mode association. For example, the command:
w32tm /configure /manualpeerlist:"0.pool.ntp.org,0x8 1.pool.ntp.org,0x8 2.pool.ntp.org,0x8" /syncfromflags:MANUAL /updatewill configure your Windows machine to form client-mode associations with three different NTP Pool servers.The minimum polling interval on all Windows machines except domain controllers is set to 1024 seconds by default. Windows domain controllers have a minimum poll interval of 64s.
This is reasonable as clients usually do not need extremely accurate time. However, quite a few servers that are not domain controllers do need to get accurate time offset and frequency synchonization quickly. You can configure “MinPollInterval” and “MaxPollInterval” through the registry or using Group Policy tools, as documented here.
Important note: never set the minimum poll value to less than 6 (which is 26 = 64 seconds). You won’t get better time synchronization, and will be abusing the servers you have configured. Many time server administrators have automated tools that block clients that poll too frequently.
Windows Time Service does follow sensible rules for “backing off” the polling interval, and adjusting the interval to network conditions. In my testing, a Windows Server 2003 domain controller began polling at 64 seconds, and then backed off to one poll every 1024 seconds within about 30 minutes. This is the same behavior as the reference ntpd implementation.
Also, in my tests, Windows Time Service did respond to unreachable servers sensibly, backing off the polling interval to 215s. However, when a server became unreachable, it did increase polling in steps down to 24s before reverting to 215s. This rather strange polling pattern (15-9-9-8-7-6-5-4) continued until the server became reachable again. There have been quite a few problems in the past caused by NTP implementations that polled too frequently. Fortunatley, the Windows Time Service should not cause problems in this area, as an unreachable server results in an average of one poll every 212s (about once an hour).
Comments:
matt -
So, you enforce a polling interval on your DCs (and PDC emulator)? I also have a few clients that need to have very accurate time. I’m going to test having them sync directly to a level 3 internet ntp.
RPM -
By setting Windows Time Service to create client-mode NTP associations (basically put “,0x8” after the ntp server name in your configuration), Windows will adjust the polling interval automatically from 64 to 1024 seconds based on the needs of the clock filter. This is the same behavior as the reference ntpd.
Polling more frequently does not necessarily give you “better” time - longer poll intervals make the clock more stable. The reasons are complex, but there is a short synopsis here.
Finally, using a short poll interval (<60s) against other people's servers is considered rude, and some NTP implementations will simply start dropping your requests or end you a Kiss-of-Death packet if you poll too frequently.