Or you can ask the it guys to use a windows server... Eg:
That is a joke Jared? You left off the smiley. Windows doesn't do NTP out-of-the-box (Microsoft assertions to the contrary notwithstanding). You can build a reasonably working standard daemon, however don't expect time to be very accurate. Windows out-of-the-box can keep time +/- 10 minutes or so using the Microsoft lets-pretend-NTP. You can build the current standard NTPD distribution on Windows. You can also spend lots of time to make it "work as well as possible" (once you manage to get it to compile, that is). Even so, when you have configured it to the optimality of accuracy, this is what you can expect: remote refid st t when poll reach delay offset jitter ============================================================================== +tic.nrc.ca .PPS. 1 u 13 64 377 55.544 5.913 0.870 -tac.nrc.ca .ATOM. 1 u 48 64 377 56.188 4.768 3.041 -toc.nrc.ca .ATOM. 1 u 1 64 377 55.485 4.758 0.981 +tick.usask.ca .GPS. 1 u 34 64 377 19.566 6.942 5.699 *tock.usask.ca .GPS. 1 u 29 64 377 19.665 5.955 1.937 -clock.isc.org .GPS. 1 u 37 64 377 53.091 8.311 0.649 +clock.sjc.he.ne .CDMA. 1 u 48 64 377 43.591 6.066 2.501 offset: 0.005955 s frequency: 23.346 ppm poll adjust: -30 watchdog timer: 47 s is about the best you will get. Statistics are pretty awful: Date # O.Avg O.Median O.Range O.CI O.Skew O.Kurt F.Avg F.Median F.Range F.CI F.Kurt 2012-01 899 0.765559 0.004198 20.05221 0.000371 -0.56023 0.751151 21.31698 20.9705 2.9685 0.108050 -0.88068 2012-02 9673 0.237434 -7.46502 59.75607 0.000156 -1.43583 8.609085 19.01126 19.3495 5.2995 0.040683 -0.54578 2012-03 1380 -0.02157 -14.8416 44.00043 0.000124 -1.08589 4.559049 18.08941 16.822 7.536 0.045387 0.268831 2012-04 1322 0.196654 21.16261 106.1250 0.000141 -0.48643 26.05868 17.56811 16.812 6.111 0.040561 -0.38021 2012-05 8849 0.118125 27.44213 72.01526 0.000161 0.296114 8.939429 17.88685 15.2595 9.3195 0.080186 1.121740 2012-06 1457 0.409662 -20.2809 63.32684 0.000114 -1.44144 11.98237 20.50724 19.5425 6.7425 0.042372 -0.08891 6102 0.201651 21.16261 106.1250 6.065429 -0.84354 13.78161 18.71838 16.1125 10.1725 0.023443 1.215941 This is from a custom ntpd build using the highest precision that it can manage to coerce from Windoze. Of course, this may be accurate enough for most uses -- at least it does not have to time-step. Doesn't compare to ntpd on linux on an 80286 with 640K ram booting from a floppy, which can maintain time sync within less than 1 ms easily. --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org
I don't understand why anyone would use windows server for anything that needed precision like time. On Sat, Jun 30, 2012 at 5:39 PM, Keith Medcalf <kmedcalf@dessus.com> wrote:
Or you can ask the it guys to use a windows server... Eg:
That is a joke Jared? You left off the smiley.
Windows doesn't do NTP out-of-the-box (Microsoft assertions to the contrary notwithstanding). You can build a reasonably working standard daemon, however don't expect time to be very accurate. Windows out-of-the-box can keep time +/- 10 minutes or so using the Microsoft lets-pretend-NTP.
You can build the current standard NTPD distribution on Windows. You can also spend lots of time to make it "work as well as possible" (once you manage to get it to compile, that is). Even so, when you have configured it to the optimality of accuracy, this is what you can expect:
remote refid st t when poll reach delay offset jitter
============================================================================== +tic.nrc.ca .PPS. 1 u 13 64 377 55.544 5.913 0.870 -tac.nrc.ca .ATOM. 1 u 48 64 377 56.188 4.768 3.041 -toc.nrc.ca .ATOM. 1 u 1 64 377 55.485 4.758 0.981 +tick.usask.ca .GPS. 1 u 34 64 377 19.566 6.942 5.699 *tock.usask.ca .GPS. 1 u 29 64 377 19.665 5.955 1.937 -clock.isc.org .GPS. 1 u 37 64 377 53.091 8.311 0.649 +clock.sjc.he.ne .CDMA. 1 u 48 64 377 43.591 6.066 2.501
offset: 0.005955 s frequency: 23.346 ppm poll adjust: -30 watchdog timer: 47 s
is about the best you will get. Statistics are pretty awful:
Date # O.Avg O.Median O.Range O.CI O.Skew O.Kurt F.Avg F.Median F.Range F.CI F.Kurt 2012-01 899 0.765559 0.004198 20.05221 0.000371 -0.56023 0.751151 21.31698 20.9705 2.9685 0.108050 -0.88068 2012-02 9673 0.237434 -7.46502 59.75607 0.000156 -1.43583 8.609085 19.01126 19.3495 5.2995 0.040683 -0.54578 2012-03 1380 -0.02157 -14.8416 44.00043 0.000124 -1.08589 4.559049 18.08941 16.822 7.536 0.045387 0.268831 2012-04 1322 0.196654 21.16261 106.1250 0.000141 -0.48643 26.05868 17.56811 16.812 6.111 0.040561 -0.38021 2012-05 8849 0.118125 27.44213 72.01526 0.000161 0.296114 8.939429 17.88685 15.2595 9.3195 0.080186 1.121740 2012-06 1457 0.409662 -20.2809 63.32684 0.000114 -1.44144 11.98237 20.50724 19.5425 6.7425 0.042372 -0.08891 6102 0.201651 21.16261 106.1250 6.065429 -0.84354 13.78161 18.71838 16.1125 10.1725 0.023443 1.215941
This is from a custom ntpd build using the highest precision that it can manage to coerce from Windoze.
Of course, this may be accurate enough for most uses -- at least it does not have to time-step.
Doesn't compare to ntpd on linux on an 80286 with 640K ram booting from a floppy, which can maintain time sync within less than 1 ms easily.
--- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org
You could have saved yourself a bit of typing by leaving off the last 5 words of that sentence. ;) - Pete On 6/30/2012 6:42 PM, Grant Ridder wrote:
I don't understand why anyone would use windows server for anything that needed precision like time.
On Sat, Jun 30, 2012 at 5:39 PM, Keith Medcalf <kmedcalf@dessus.com> wrote:
On 6/30/12, Grant Ridder <shortdudey123@gmail.com> wrote:
I don't understand why anyone would use windows server for anything that needed precision like time.
Probably because they realize that in a Windows domain, their domain controllers already provide a SNTP service with the Windows NT PDC Emulator providing authoritative time for windows time service, and all those windows servers can be enabled as a NTP server with a small configuration change, and Windows Domain clients are required to be synchronized with this using the Windows time service, as a condition for Kerberos authentication and domain logon, for the configuration to be a supported one. So, given you already have those capabilities and those constraints... how do you justify deploying another server for providing a separate time service, running a new OS, instead of just using the same one for all hosts? In many cases it's not "Why use a windows time server" that has to be justified; the burden of proof is to answer the question "What can you say that indicates you should definitely not use a windows time server for the application?" :) -- -JH
Many folks have more than just windows desktop PCs syncing their time. If your application requires sub-5 second accuracy, (such as end of a banking day), then Windows NTP is unsuitable for the purpose. If your only objective is to sync the times on a bunch of user laptops so they can get Kerbeos tickets within the 5 minute tolerance, it works fine. For me, even a few seconds apart can be frustrating for comparing log files between busy devices. Your reason would be whether or not you fall inside or outside the Microsoft guidelines below:
From Microsoft:
http://support.microsoft.com/kb/939322 We do not guarantee and we do not support the accuracy of the W32Time service between nodes on a network. The W32Time service is not a full-featured NTP solution that meets time-sensitive application needs. The W32Time service is primarily designed to do the following: - Make the Kerberos version 5 authentication protocol work. - Provide loose sync time for client computers. The W32Time service cannot reliably maintain sync time to the range of 1 to 2 seconds. Such tolerances are outside the design specification of the W32Time service. On Sat, Jun 30, 2012 at 5:23 PM, Jimmy Hess <mysidia@gmail.com> wrote:
On 6/30/12, Grant Ridder <shortdudey123@gmail.com> wrote:
I don't understand why anyone would use windows server for anything that needed precision like time.
Probably because they realize that in a Windows domain, their domain controllers already provide a SNTP service with the Windows NT PDC Emulator providing authoritative time for windows time service, and all those windows servers can be enabled as a NTP server with a small configuration change, and Windows Domain clients are required to be synchronized with this using the Windows time service, as a condition for Kerberos authentication and domain logon, for the configuration to be a supported one.
So, given you already have those capabilities and those constraints... how do you justify deploying another server for providing a separate time service, running a new OS, instead of just using the same one for all hosts?
In many cases it's not "Why use a windows time server" that has to be justified; the burden of proof is to answer the question "What can you say that indicates you should definitely not use a windows time server for the application?" :)
-- -JH
On 7/1/12, PC <paul4004@gmail.com> wrote:
If your application requires sub-5 second accuracy, (such as end of a banking day), then Windows NTP is unsuitable for the purpose. Looks like CYA on Microsoft's part.
That i've seen, Windows NTP in physical environments with a hardware system clock not having issues consistently provides accuracy better than +/- 0.5 against the time source it's synced with, but in virtual environments, which have incompatibilities with high sub-second RTC accuracy in the first place, neither Windows nor Unix NTP services are able to provide that consistently without much tinkering. If it's absolutely critical that you have sub-5 second accuracy, even Unix NTP is not to be considered good enough, you need highly accurate hardware time source, something more accurate than the usual system clock you find in a PC or server. Unix NTP can only do so much to correct for a broken system clock; although it does do a very good job disciplining PC real-time clocks that consistently run a bit too fast or too slow, ultimately the personal computer clocks can at times be unreliable.... If they were perfect, you wouldn't need time sync in the first place; just set them once, and correct the annual 0.01 seconds worth of error once a year.... -- -JH
participants (5)
-
Grant Ridder -
Jimmy Hess -
Keith Medcalf -
PC -
Peter Kristolaitis