Re: [c-nsp] NTP Servers
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 mysi...@gmail.com wrote: On 6/30/12, Grant Ridder shortdudey...@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
Re: [c-nsp] NTP Servers
On 7/1/12, PC paul4...@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
RE: [c-nsp] NTP Servers
those. The beauty of most appliances is that they're easy to manage. If it fails, download the latest ISO from company, burn it, boot appliance, restore it and you're back in business in an hour or so. Keep in mind a linux kernel running just ntpd and some management necessities like ssh and http is pretty reliable. Hardly any I/O, just a simple function it does. http is a frilly pink bauble, not a management necessity. Very basic linux with no frilly bauble's, ntpd, sshd, and vi. Supports thousands of clients on a $10 80286 with 640KB RAM booting from a floppy. Add $1000 and you can get the same thing as an appliance. --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org
RE: [c-nsp] NTP Servers
Or you can ask the it guys to use a windows server... Eg: http://support.microsoft.com/kb/816042 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.5445.913 0.870 -tac.nrc.ca .ATOM. 1 u 48 64 377 56.1884.768 3.041 -toc.nrc.ca .ATOM. 1 u1 64 377 55.4854.758 0.981 +tick.usask.ca .GPS.1 u 34 64 377 19.5666.942 5.699 *tock.usask.ca .GPS.1 u 29 64 377 19.6655.955 1.937 -clock.isc.org .GPS.1 u 37 64 377 53.0918.311 0.649 +clock.sjc.he.ne .CDMA. 1 u 48 64 377 43.5916.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.SkewO.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.96850.108050 -0.88068 2012-02 9673 0.237434 -7.46502 59.75607 0.000156 -1.43583 8.609085 19.01126 19.3495 5.29950.040683 -0.54578 2012-03 1380 -0.02157 -14.8416 44.00043 0.000124 -1.08589 4.559049 18.08941 16.8227.536 0.045387 0.268831 2012-04 1322 0.196654 21.16261 106.1250 0.000141 -0.48643 26.05868 17.56811 16.8126.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.31950.080186 1.121740 2012-06 1457 0.409662 -20.2809 63.32684 0.000114 -1.44144 11.98237 20.50724 19.5425 6.74250.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
Re: [c-nsp] NTP Servers
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 kmedc...@dessus.com wrote: Or you can ask the it guys to use a windows server... Eg: http://support.microsoft.com/kb/816042 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.5445.913 0.870 -tac.nrc.ca .ATOM. 1 u 48 64 377 56.1884.768 3.041 -toc.nrc.ca .ATOM. 1 u1 64 377 55.4854.758 0.981 +tick.usask.ca .GPS.1 u 34 64 377 19.5666.942 5.699 *tock.usask.ca .GPS.1 u 29 64 377 19.6655.955 1.937 -clock.isc.org .GPS.1 u 37 64 377 53.0918.311 0.649 +clock.sjc.he.ne .CDMA. 1 u 48 64 377 43.5916.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.KurtF.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.96850.108050 -0.88068 2012-02 9673 0.237434 -7.46502 59.75607 0.000156 -1.43583 8.609085 19.01126 19.3495 5.29950.040683 -0.54578 2012-03 1380 -0.02157 -14.8416 44.00043 0.000124 -1.08589 4.559049 18.08941 16.8227.536 0.045387 0.268831 2012-04 1322 0.196654 21.16261 106.1250 0.000141 -0.48643 26.05868 17.56811 16.8126.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.31950.080186 1.121740 2012-06 1457 0.409662 -20.2809 63.32684 0.000114 -1.44144 11.98237 20.50724 19.5425 6.74250.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
Re: [c-nsp] NTP Servers
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 kmedc...@dessus.com wrote: smime.p7s Description: S/MIME Cryptographic Signature
Re: [c-nsp] NTP Servers
On 6/30/12, Grant Ridder shortdudey...@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
